A slave needs to have a directory dedicated to Jenkins. Specify
the path of this work directory on the slave. It is best to use
an absolute path, such as '/var/jenkins' or 'c:\jenkins'. This
should be a path local to the slave machine. There's no need for
this path to be visible from the master, under normal circumstances.
Slaves do not maintain important data (other than active workspaces
of projects last built on it), so you can possibly set the slave
workspace to a temporary directory. The only downside of doing this
is that you may lose the up-to-date workspace if the slave is turned off.
If you use a relative path, such as './jenkins-slave', the path will
be relative to the current working directory that the launcher provides.
- For launchers where Jenkins controls starting the slave process, such
as SSH, the current working directory will typically be consistent,
e.g. the user's home directory. This means that Jenkins will be able to
rely on the caching of tool installations and workspaces from previous
builds.
- For launchers where Jenkins has no control over starting the slave
process, such as JNLP when launched from either the command line or via
a web browser link, the current working directory may change between
launches of the slave and use of a relative path may prove problematic.
The principal issue encountered when using relative paths with launchers
like JNLP is the proliferation of stale workspaces and tool installation
on the slave machine. This can cause disk space issues.
Note: there are some cloud providers that specifically use relative
paths with the JNLP launcher to allow for dynamically provisioned pools
of semi-heterogeneous slaves.