reading and writing from master to slave

[Tal Yanai]

Hi,

I have a Java plugin (regular step) that is always running on the Master.   The setup is also having an additional Node slave.  The builds runs on the slave.

The Java step plugin need to gain access to some files within the build's workspace.  In order to achieve that, I'm doing the following:

if(build.getWorkspace().isRemote()){

  channel = (hudson.remoting.Channel) build.getExecutor().getCurrentWorkspace().getChannel();

  hudson.FilePath newFile = new hudson.FilePath(channel, fileOnDiskPath);

}

From here I suppose I can read/write remotely into the salve machine.  

This works OK when "build" is AbstractBuild, but it's a puzzle to me how do I get it when 'build' is from type "hudson.model.Run".   

I tried build.getExecutor().getCurrentWorkspace() but the Workspace always returns as Null.  

Thanks,

Tal.

[Jesse Glick]

On Tue, Oct 29, 2019 at 8:47 AM Tal Yanai <t...@yanai.org.il> wrote:
> if(build.getWorkspace().isRemote()){
> channel = (hudson.remoting.Channel) build.getExecutor().getCurrentWorkspace().getChannel();
> hudson.FilePath newFile = new hudson.FilePath(channel, fileOnDiskPath);
> }

No need to check `isRemote` nor to cast to `Channel` nor to call the
`FilePath` constructor manually. Just use

FilePath newFile = build.getWorkspace().child(fileOnDiskPath);

unconditionally. You would typically pass a relative pathname; see:
https://javadoc.jenkins.io/hudson/FilePath.html#child-java.lang.String-

> This works OK when "build" is AbstractBuild, but it's a puzzle to me how do I get it when 'build' is from type "hudson.model.Run".

For a Pipeline build? There is no equivalent concept. A `FilePath
workspace` will be provided to you from various extension points, in
this case probably `SimpleBuildStep`:

https://jenkins.io/doc/developer/plugin-development/pipeline-integration/#basic-update

[Tal Yanai]

Thanks Jesse, that helped.

If I understood correctly, there's not necessarily one node's workspace for a given build of Pipeline.  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?

Thanks,

Tal.

[Jesse Glick]

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.

[Markus Winter]

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).