Not specific to the perforce plugin... I don't really see any reason to be syncing the source code down on the parent job when no 'touchstone' build is being executed, but Jenkins goes ahead and syncs it anyways (presumably to grab changes, but those should be easily retrievable from the children).

Thanks for clarifying Rob. Any idea who this issue could be assigned to so the problem is fixed? I'm unclear on this assignment/fix process. From the replies on the mailing list and a quick look in Jira it appears this problem is affecting other users too.

Many thanks,
Tom

It's already assigned to core, so someone will pick it up from there. I recommend voting on it to give it some more attention.

What's even worse is for subversion it seems to sync the entire depo rather than using the exclude directory list, which is taking hours to sync...

So 7 months further down the line and still no word on this

Hi Kohsuke,

Are there any plans to fix this any time soon?

Tom

Is this ever going to be fixed?

Tom

I've hit this recently with svn too:

https://groups.google.com/forum/?fromgroups=#!topic/jenkinsci-users/JAE9lxU4jZ8

It's also the pre-build steps that get executed, so the 'delete workspace' plugin can cause problems.

As a further thing, the throttle concurrent builds plugin works on parent or child builds of a matrix, depending on which version you have, but never both.

As an additional note, if there are numerous projects configured to use a Matrix build then the master machine can be really hobbled as it tries to simultaneously sync all the projects that exist. This sync phase does not get queued because it doesn't require an executor to run, it's just the master preparing itself to tell the slaves to do something.

As a result, the master machine ends up crawling as the disk usage goes through the roof from many (large) projects syncing at once.

Changing this to "improvement" as the code is functioning as designed. It's just that Jenkins can do it smarter.

Out of curiosity: why was it designed this way? I can't see any benefit to executing the pre-build steps in the parent job; they're not using by the child jobs at all, as best I can tell...

This feature causes my builds to fail sporadically. Most of my jobs are set up to use the same custom workspace. So when this second sync occurs on top of a running job, it starts modifying the workspace while building.

Ryan: yep, that was my experience too. The workaround is to use the Tie Parent plugin, and tie all matrix parent jobs to a "sacrificial node", that node should do nothing else other than run matrix parent jobs.

So any ideas when this improvement might be implemented? Seems like its something jenkins users want to see fixed.

Tom

Matrix job by design require both head build and all axes to run SCM operations :

• head to determine the revision to build, and trigger all axes builds accordingly
• axes to prepare workspace in sync with revision to build.

see for sample Git-plugin support for matrix jobs : https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L845

probably some SCM can do some light weight operation when they already know the revision to checkout, vs a full fetch from matrix head, but they will anyway have to do some stuff BOTH on axes and head.

Specifically for Perforce, I've managed to get some improvement by running a local Perforce proxy. This caches commonly accessed files locally. The first query pulls all of the files into the cache, and then the synch for each matrix configuration just reads the files out of the cache.

Charles

As the matrix functionality has now moved from the core maybe this issue should be moved to the Matrix Project plugin, or maybe to the Perforce plugin as it seems the 'fix' is most likely to be optimizations to reduce syncing in the P4 plugins itself (if possible).

The issue is that the matrix plugin syncs during the main job, which shouldn't be mandatory as it doesn't normally do anything. Perforce is as optimized as it can possibly get.