[#QB-3379] Some groovy expressions evaluate differently in trigger steps than they do in regular build steps.

QuickBuild

Some groovy expressions evaluate differently in trigger steps than they do in regular build steps.

Created: 24/Apr/19 12:17 AM Updated: 11/Mar/20 08:55 AM

Return to search

Component/s:

None

Affects Version/s:

6.1.34

Fix Version/s:

None

Original Estimate:	Unknown	Remaining Estimate:	Unknown	Time Spent:	Unknown
Environment:	Linux, CentOS6 & 7

Description

« Hide

I'm having some mvel expressions that evaluate differently in different places; in once case I get different answers, in the other case, the expression works in one and fails in the other.

Background: I have a configuration A that triggers a build of configuration B and copies back files from B.

Problem 1)
I need to provide the full path to B's workspace. (Since the implied workspace for copying back seems to be A's.) When I use ${system.getConfiguration("/path/b").getWorkspaceDir()} in the trigger step, it does not yield B's workspace (it appears to yield A's workspace). However, it yields B's workspace when I use it in a plain build step (running a shell and printing the value).

Problem 2)
I was originally trying to get B to run on the same node as A. I passed A's name and port as a parameter: ${current.getNode().getHostName()}:${current.getNode().getPort()}
This failed, with a message about mvel not able to evaluate the expression. If I create a regular build step and use that exact same expression, it evaluates fine.

Am I doing something wrong? Is there something special about the environment in a trigger step when these are evaluated?

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Robin Shen [25/Apr/19 12:40 AM]

For problem 1), where are you using the script? Is it in the post-execute action of the trigger build step?

For problem 2), please use ${step.getNode().getHostName()}:${step.getNode().getPort()}. As current has different meanings in different context. It refers to the parameter itself when used in parameter definition.

[ Permlink | « Hide ]

Paul Gross [25/Apr/19 08:56 PM]

For problem 1) I am using the script in the "Send Output Files" section of the step, specifically for the "Source Path".
I found that if I use a relative path, the workspace directory is that of the triggering step, not the triggered configuration, so I wanted to be able to look up the workspace dir for the triggered configuration. (That's better than hard-coding the path, which I'm doing now, but it would be even nicer if I could refer to the "Configuration" field in the triggering step to avoid duplicating that string.)

For problem 2) thank you for the answer. I may not need to use that construct, but I appreciate having the correct one and the insight about how the meaning of "current" can change.

[ Permlink | « Hide ]

Robin Shen [25/Apr/19 11:10 PM]

The input/output is a general setting of steps, and it is designed to transfer files between different steps in same build, so it by default uses work space of current build. In your case, you may script the source path as below to use workspace of triggered configuration:

${groovy:
def triggeredBuildId = step.runtime.customData;
def triggeredConfiguration = system.buildManager.load(triggeredBuildId).configuration;
return triggeredConfiguration.workspaceDir.absolutePath + "/dir_containing_your_files";
}

[ Permlink | « Hide ]

Paul Gross [26/Apr/19 06:27 PM]

That still yields the workspace directory of the triggering configuration.

I added some step by step debugging:
- logger.info(triggeredConfiguration) yielded the correct configuration (B in my example).
- logger.info(triggeredConfiguration.workspaceDir) yielded A's workspace directory.

Could this be a problem with our Quickbuild version, as it's rather old?

[ Permlink | « Hide ]

Robin Shen [27/Apr/19 12:24 AM]

This is odd. Are you able to reproduce this issue with a sample database and send it to [robin AT pmease DOT com]?