-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins LTS (1.424.1) on Debian Squeeze (with debian and freebsd slaves
I have a (few) matrix jobs on a distributed build environment, I'm using SCM(SVN) polling using "Emulate clean checkout by first deleting unversioned/ignored files, then 'svn update'" strategy.
I just noticed that sometimes a random configuration job from my matrix job lose it's workspace, and has to do a clean checkout:
"Checking out a fresh workspace because there's no workspace at /home/jenkins/workspace/php-src-5.4-matrix-build"
After experiencing it a few times I also noticed, that it is correlated to the other issue, that I was seeing, namely that sometimes the flyweight build of my matrix job gets executed on a different node that I was pinning to using the matrix tie parent plugin.
Of course executing that on a different node means that it has to do a clean checkout from SCM, and this is when I got enlightened:
- the flyweight build will use $JENKINS_HOME/$JOB_NAME as the workspace directory
- the configuration jobs will use the $JENKINS_HOME/$JOB_NAME/$AXES
This means that if both the flyweight and one of the configuration jobs will be executed on the same node, they will interfere with each others workspaces.
What I see to happen, is that the flyweight job will delete everything from $JENKINS_HOME/$JOB_NAME, and create a clean checkout there.
Which in turn will force my configuration build to also do a clean checkout, as it won't find it's workspace.
I created a bug report for the immediate problem (which made this issue visible for me): that the matrix tie parent plugin won't schedule the flyweight job to the tied label in some cases:
https://issues.jenkins-ci.org/browse/JENKINS-11987
The author of that plugin confirmed, that this could indeed happen, and marked the bug as "Not A Defect".
Now I don't really see a way to prevent this issue from happening, as the matrix tie parent can only reduce this situation, but not prevent it, and I can't tell jenkins to use a different workspace path for the flyweight and the configuration job(different == one of them not containing the other one).
Do you think that this could be fixed somehow, or do you know any workaround for this problem?
- is related to
-
JENKINS-5076 Master job of multiconfig project can be executed on hosts that are marked as "Leave this machine for tied jobs only"
- Reopened