-
Improvement
-
Resolution: Fixed
-
Major
-
None
JENKINS-5077 created the ability to use custom workspaces in matrix jobs, however the implementation keeps the creation of a subtree specific to the axis and target (e.g. ${WORKSPACE}/axis1/a/axis2/b). This doesnt make sense some (most?) of the time as you're then not actually in the custom workspace you defined, but instead inside a subtree.
We need an option to disable this subtree creation so that all runs of a matrix job can share the root of a custom workspace.
- is related to
-
-
- Open
-
[JENKINS-8317] Matrix jobs with custom workspaces should be able to share the root with no axis-specific subtree
mleinart
added a comment - My current workaround for this issue is to do
cd ../../
In my shell build step before doing anything else. Where this really screws me up though is collecting reports and publishing artifacts as the paths dont support ".." nor non-relative URLs
mleinart
added a comment - My current workaround for this issue is to do
cd ../../
In my shell build step before doing anything else. Where this really screws me up though is collecting reports and publishing artifacts as the paths dont support ".." nor non-relative URLs mleinart
added a comment - Proposed fix at https://github.com/mleinart/hudson/tree/JENKINS-8317
Pull request submitted
mleinart
added a comment - Proposed fix at https://github.com/mleinart/hudson/tree/JENKINS-8317
Pull request submitted Discussion about the pull request at https://github.com/hudson/hudson/pull/7
Andy M
added a comment - Any update on this? The aforementioned discussion about the pull request seems unrelated?
Andy M
added a comment - Any update on this? The aforementioned discussion about the pull request seems unrelated? 
Joel Pearson
added a comment - We also need this fixed. We're doing the cd ../../ fix at the moment, but it kinda sucks because we have to disable scm integration and run the scm commands inside a shell build step.
Joel Pearson
added a comment - We also need this fixed. We're doing the cd ../../ fix at the moment, but it kinda sucks because we have to disable scm integration and run the scm commands inside a shell build step. Joel Pearson
added a comment - It turns out it was fixed in 1.467 3 days ago:
Matrix custom workspace support is improved to allow configuration builds to share workspace
You just set the "Directory for sub-builds" to "."
Joel Pearson
added a comment - It turns out it was fixed in 1.467 3 days ago:
Matrix custom workspace support is improved to allow configuration builds to share workspace
You just set the "Directory for sub-builds" to "." 
Emil Styrke
added a comment - This seems to be only part of the solution. I'm using the "Clone workspace" plugin to populate the workspace, and even when setting the directory for sub-builds to ".", each sub-build (as well as the main build) will unpack the workspace (to the same location). There seems to be no way to specify that the sub-builds should ignore the SCM step altogether.
Emil Styrke
added a comment - This seems to be only part of the solution. I'm using the "Clone workspace" plugin to populate the workspace, and even when setting the directory for sub-builds to ".", each sub-build (as well as the main build) will unpack the workspace (to the same location). There seems to be no way to specify that the sub-builds should ignore the SCM step altogether. 
Related to JENKINS-4285 but this issue is a more-specific case as the general case isn't nearly as clear to me - non-custom workspace means a non-dummy workspace lease and also implies SCM checkouts in which case truely sharing a workspace doesn't make sense (to me).