Your browser was unable to load all of the resources. They may
have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.
Hello,
I am aware that it is possible to pass artefacts from configuration to configuration via promotion. However is it possible to do this with triggered builds. e.g.
The first build step in ConfA triggers a build in ConfB. ConfA passes a file to ConfB then collects the result at the end. I thought I could achieve this via the Fetch Input Files and Send Output Files, however this does not seem to work.
Essentially what I want is to define a configuration that performs some operation on a supplied file that will be dropped into the root of its workspace. I then want to define a second build that may perform a checkout and invoke the first build for each file that was checked out, collecting output from the first build as it goes.
I am aware that I could simply put the file to process in a shared location and pass a variable to the first build informing it of the location of the file. However I was hoping for something more elegant.
-
replies
5
-
views
2686
-
stars
0
-
Define a variable in the step triggering configB to carry over the node address, for instance:
name: fileNode
value: ${node.address}
Then edit master step of configB to use setting "On node with address equals to value of specified variable" for "node selection", and choose variable to be fileNode (QB populated the variable choice list from defined variables seen by configB, so you will need to define fileNode variable with empty value at configB variables page also).
With this, master step of configB is ganranteed to be running at the same node as the trigger build step defined in configA, and then it can access files transferred via "fetch input/send output" option of the trigger build step by directly visiting workspace of configA.
So I would need to pass the address of the node on which ConfigB should run as well as the path to ConfigA so that ConfigB can fetch and send the output files.
Unfortunately this implies that ConfigA and B can run on the same machine. Perhaps ConfigA could include a step that runs on the machine that will run ConfigB, I could then transfer files to that step and then trigger the ConfigB build in a later step. However I now need to embed the resource requirements of ConfigB into a step in ConfigA so that it can select an appropriate machine, this will be a headache to maintain.
What we were hoping to achieve was a simplification of our current build configurations by constructing a set of utility configurations that could be triggered as and when required e.g.
ConfigA:
- Step1 Check out some source code.
- Step2 Trigger a build that runs PC-Lint over the source code (transfer source files to the PC-Lint configuration).
- Step3 Process the results of PC-Lint (send the PC-Lint results back to ConfigA).
- Step4 Build the project if the PC-Lint results do not indicate any errors.
Now my PC-Lint configuration may include many steps, but is potentially generic enough that it can just operate on a list of supplied files.
If it is not possible to fetch and send files efficiently between triggered builds on different machines then I would have to embed my PC-Lint steps in each build.
Then I'd suggest to go with the step re-use approach. After all, the step itself can be contain as many child steps as you want and can accept parameters to make it generic enough to be reused in many configurations.
So you are suggesting that I define a set of steps in a parent configuration so that they can be used in all child configurations. This could work, I can see some complexity in that some steps will want to clean the workspace first which will affect the build into which they are embeded, so I would have to use a node selection script that avoided using the same node as the parent build. I imagine that my root configuration will end up with a lot of utility steps.
As an alternative is it possible (potentially via a Groovy script) to fetch files from a remote machine, given the host name, folder etc. In this way I can simply pass the name of the folder, host name etc. that contains the input files to the triggered build and rely upon the triggered build to fetch them. QuickBuild must already have this functionality to some extent as it is able to send and fetch files between steps that are run on different machines.
The methods used by QB to transfer files can be accessed from grid object, they have below sigatures:
void transferFiles(GridNode fromNode, String srcDir,
String filePatterns, GridNode toNode, String destDir,
boolean compress, String lockForReadPath, String lockForWritePath);
void transferFile(GridNode fromNode, String srcFile,
GridNode toNode, String destFile, String lockForReadPath,
String lockForWritePath);
So you will be able to do this via groovy.
