|
|
|
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. 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"; } 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? This is odd. Are you able to reproduce this issue with a sample database and send it to [robin AT pmease DOT com]?
|
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.