Thanks for the suggestion of using $WORKSPACE, that's an improvement. I
still don't know why Jenkins thought the primary workspace was in use but
since the problem has disappeared, I won't worry about it for now.
On Tue, Oct 30, 2018 at 10:09 AM matthew.web...@diamond.ac.uk <
>> Is there some way for me to find out *why* Jenkins thought the default named
>> workspace was already in use? Our scripts make assumptions about the
>> workspace location and if Jenkins appends something ("@2") to the name of
>> the folder it won't work.
It's very strange that Jenkins
Is there some way for me to find out *why* Jenkins thought the default
named workspace was already in use? Our scripts make assumptions about the
workspace location and if Jenkins appends something ("@2") to the name of
the folder it won't work.
On Tue, Oct 30, 2018 at 2:25 AM Mark Waite
wrote:
Those workspace names are not an indication of an incompatibility. If
Jenkins needs to allocate a workspace and it detects that the default named
workspace is already in use, it will allocate a second workspace adjacent
to the first, with a digit appended to the workspace name.
Mark Waite
On
Today I installed the version of Java from 8 build 181 to 8 build 191 on
several build slaves. After doing that, Jenkins started allocating a 2nd
workspace on the some of the build agents. For example, instead of running
here:
D:\projects\lion\main
They were running here:
