Removal of Workspace root option causes fallback to system wide default

[jdelee]

Jenkins and plugins versions report:

Jenkins: 2.303.2
OS: Linux - 5.11.0-1020-aws
---
nomad:0.9.0

• What Operating System are you using (both controller, and any agents involved in the problem)?

ubuntu 20.0.4

In release 0.8.0 Workspace root was used to specify the value of -workDir executed by the slave/agent.jar, but it also modified the remoteFS property for the node affecting the location of the workspace on the remote system.

With the removal of this option, the workspaceDir on the remote now defaults to the system property value hudson.model.slave.workspaceDir

please restore the ability to specify remoteFS for the remote node to accommodate setting unique workspaceDirs

[multani]

@jdelee Thanks for the report, I'll look at that soon.

@j3t Do you think you could give a hand here?

[multani]

I guess this is due to this change: we should pass remoteFs instead of "" to the parent constructor.

[j3t]

I can take a look but I have to reproduce it first.

[j3t]

In release 0.8.0 Workspace root was used to specify the value of -workDir executed by the slave/agent.jar, but it also modified the remoteFS property for the node affecting the location of the workspace on the remote system.

I got it. You can define the -workDir parameter to start up the remote agent but on Jenkins side the -workDir parameter is ignored and the hudson.model.slave.workspaceDir parameter is used instead. I'm wondering, is there a way that the -workDir parameter from the remote agent is not ignored by Jenkins? I mean the remote agent is started with the correct -workDir, right?

[j3t]

Unfortunately, I didn't find a way to make use of the -workDir provided by the remote agent. The only way seems to be to specify it twice (in the job template and as field so that it can used to create the computer in Jenkins).

[multani]

What about setting it once, as a new form field, exporting it as a new "Job variable", that can be reused or not?

Something like WORKER_NAME, but then, it's up to the job writer to decide to use it or not.

[j3t]

What about setting it once, as a new form field, exporting it as a new "Job variable", that can be reused or not?

Yes, I thought about that too and I would prefer WORKER_DIR.

Unfortunately, I didn't find a way to make use of the -workDir provided by the remote agent.

It seem like that the only purpose of the -workDir parameter is to verify that the directory exists and is accessible (see https://github.com/jenkinsci/remoting/blob/master/src/main/java/org/jenkinsci/remoting/engine/WorkDirManager.java#L201). I haven't found any other usage.

[multani]

@jdelee I merged and release @j3t fix in v0.9.1: you should be able to configure the root workspace again and reuse it in the template via the %WORKER_DIR% template variable.

Let us know if that works for you!