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

[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" block. Thoughts? Thanks!

A.

[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: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/build-test.groovy#L100

Then, I used the NodeLabel Parameter plugin to define BUILD_NODE.

 

--

Craig

[Michael Neale]

Craig, does that mean that you have a label specific for each node? as otherwise, if there are multiple ones, that won't necessarily pick the same one. 

[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 "special" workspace.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/cd6d93ae-52fe-4900-93bd-680b78f6d86f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[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

[somai.a...@gmail.com]

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, afterwards you will be able to define a downstream job that shall be able to use the same workspace as the upstream job. Some features that the plugin will have can be found here: https://github.com/martinda/external-workspace-manager/blob/master/README.md.

When completed, I think that this plugin may be suitable to your needs.

You may also follow this mail thread: https://groups.google.com/forum/#!topic/jenkinsci-dev/nAZD0-upB68 where I will be posting updates from time to time.

Currently I am working with my mentors Oleg and Martin to define a good design strategy for the plugin. We have weekly meetings on Mondays at 12 PM (noon) UTC on http://jenkins-ci.org/hangout, where everybody can join (the next one will be on May 16th).

Regards,

Alex

[Jesse Glick]

On Mon, May 9, 2016 at 6:28 PM, Andrew Bayer <andrew...@gmail.com> wrote:
> 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" block.

def n
node {
// …
n = env.NODE_NAME
}
// …
node(n) {
// now we are on the same node
}

Think twice, maybe three times, before using this trick:

· if the node was a one-shot cloud agent, the second `node` block will
just wait forever for a node of the same name to be reattached
· while you may get the same workspace back, there is no guarantee it
has not been overwritten by a newer build, unless you have disabled
job concurrency

Using `stash`/`unstash` is safer and more general, albeit slower.