-
Bug
-
Resolution: Not A Defect
-
Blocker
-
None
*strong text*When choosing in build setting the option Execute concurrent builds if necessary, if a build is executed while another build is running, the second workspace created as workspace@2.
The use of '@' character is not so good as it is sometimes used as a meta-character in scripts.
For example, I had a problem when my script was trying to run sqlplus command where @ is used.
Consider changing '@' character with '_' or simply just using workspace2 with no character in between.
- is duplicated by
-
-
- Resolved
-
-
-
- Resolved
-
- is related to
-
-
- Open
-
[JENKINS-11519] When chosing "Execute concurrent builds if necessary" extra workspaces created should use a different character than '@'
According to darkrift on IRC, the workaround is this :
You need to add a -D parameter to the startup of jenkins : -Dhudson.slaves.WorkspaceList=! (to change it to ! for example)
michael d
added a comment - - edited According to darkrift on IRC, the workaround is this :
You need to add a -D parameter to the startup of jenkins : -Dhudson.slaves.WorkspaceList=! (to change it to ! for example) 
ejschuiteman
added a comment - That is working, thank you! So does the workaround resolve the issue, or should the default character still be changed from "@" into something else (e.g. "_")?
michael d
added a comment - the default character is still "@" but you can change it easily with the parameter above
michael d
added a comment - the default character is still "@" but you can change it easily with the parameter above I'm wondering what's the impact of changing this. Does it break anything?
Just wonder you have "Test" and "Test_4" jobs, when the first one is parallelizable...
The changing of the default hudson.slaves.WorkspaceList also leads to the re-creation of existing workspaces, hence there will be a data leak on workspace storages.
Probably, it makes sense to add the explicit definition of a new separator (not "_") to Jenkins init files in order to change separators on new installations.
If the @ leads to problems for you, set the documented System property hudson.slaves.WorkspaceList (no suffix after class name as usual!), e.g.: -Dhudson.slaves.WorkspaceList=_. I see no reason to change the default, unless it can be demonstrated to regularly cause issues.
Tim Port
added a comment - This seems to break the p4 plugin. Thanks for the workaround! 
Sean Flanigan
added a comment - Another place this can trigger a problem is if you have buggy code, perhaps in tests, that does this:
new File(fileURL.getFile());
when it should be doing this:
return new File(fileURL.toURI());
This tends to break only in concurrent builds because of the sudden appearance of @ in the workspace path.
In fact I'm thinking of setting -Dhudson.model.Slave.workspaceRoot=workspace@root to guarantee that it will happen consistently, not just when there are concurrent builds running.
Sean Flanigan
added a comment - Another place this can trigger a problem is if you have buggy code, perhaps in tests, that does this:
new File(fileURL.getFile());
when it should be doing this:
return new File(fileURL.toURI());
This tends to break only in concurrent builds because of the sudden appearance of @ in the workspace path.
In fact I'm thinking of setting -Dhudson.model.Slave.workspaceRoot=workspace@root to guarantee that it will happen consistently, not just when there are concurrent builds running. 
For reference:
https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties