[JENKINS-11993] matrix flyweight and configuration builds have "overlapping" workspace directories

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?

---
Originally reported by tyrael, imported from: matrix flyweight and configuration builds have "overlapping" workspace directories

• assignee: kbertelson
  
• status: Open
  
• priority: Major
  
• component(s): matrix-project-plugin, matrixtieparent-plugin, subversion-plugin
  
• resolution: Unresolved
  
• votes: 3
  
• watchers: 10
  
• imported: 2025-12-06
  

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?

• environment: Jenkins LTS (1.424.1) on Debian Squeeze (with debian and freebsd slaves