Re: Forcing Pipeline "node" blocks to run on the same agent/in the same workspace?

2016-05-11 Thread somai . alexandru
Hello, As part of the Google Summer of Code 2016, I will be working on a plugin called External Workspace Manager. The basic idea of this plugin is to be able to provide the same workspace for multiple jobs. For example you would have an upstream job that will run a job on a defined workspace,

Re: Forcing Pipeline "node" blocks to run on the same agent/in the same workspace?

2016-05-11 Thread Craig Rodrigues
Yes, in my case I have the same groovy script used in different jobs, and each job specifies a specific BUILD_NODE via the Node label parameter plugin. -- Craig On Monday, May 9, 2016, Michael Neale wrote: > Craig, does that mean that you have a label specific for each

Re: Forcing Pipeline "node" blocks to run on the same agent/in the same workspace?

2016-05-10 Thread Robert Sandell
The ws step will allocate a new named workspace on the current node, and if another run comes along and runs the ws step with the same name it will get the same workspace. I use it for download caching between pipelines. So if you could request the same node as before somehow you can get the same

Re: Forcing Pipeline "node" blocks to run on the same agent/in the same workspace?

2016-05-09 Thread Craig Rodrigues
Hi, What you are asking for is interesting. I couldn't figure out how to get the return status of node {} to see what node it ran on. What I did in my job instead was to create a build parameter BUILD_NODE, and then do node (BUILD_NODE) { } See:

Forcing Pipeline "node" blocks to run on the same agent/in the same workspace?

2016-05-09 Thread Andrew Bayer
i.e., something like https://wiki.jenkins-ci.org/display/JENKINS/Node+Stalker+Plugin - is there any way to do this sort of thing in Pipeline as it exists today? I *think* I'd like to be able to inspect an executed "node" block and see where it ran, and then pass that onward to a future "node"