It makes only sense when the step following the shell step is running in
the same node block. Once the node block is exited there is no
guarantuee that the file in the workspace is still available (think of
agents provided from a cloud that get destroyed directly after the node
block finished, or a parallel execution of the pipeline that directly
builds afterwards on the same node and cleans the workspace).
Something like
node('a') {
 sh ...
}
mystep("some path on node(a)")
will likely fail even when you know at execution time of mystep on which
node the sh step was running.
With this the file is a simple parameter of the step with the relative
path (assuming no other action in between has modified the workspace).
On 30.10.2019 15:39, Jesse Glick wrote:
On Wed, Oct 30, 2019 at 2:54 AM Tal Yanai <t...@yanai.org.il> wrote:
If I understood correctly, there's not necessarily one node's workspace for a
given build of Pipeline.
Correct—there could be zero, one, or many.
Is there any mechanism for a step (shell step in this case) to notify the
master (or the following plugin step) on which Node did it run? That is so the
following step (the plugin) will know from where to pick the input files
created by the shell step?
Not sure what you are getting at. Steps should be self-contained and
independent. If it needs a parameter, pass it from the script. Hard to
answer without a concrete example.
--
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/0abdb3fb-191f-871c-79ff-2a9c4159283b%40gmx.de.
