|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I don't have this problem anymore, as the project using this setup was eventually moved to git, but from a quick look into Throttle Concurrent Builds plugin, I'm not sure that this would solve the issue.
AFAIR you don't have to enable concurrent execution for the matrix job to be able to bump into this issue, and I don't see any mention about flyweight builds at https://wiki.jenkins-ci.org/display/JENKINS/Throttle+Concurrent+Builds+Plugin and even if it would affect the execution of the flyweight jobs, this issue isn't about executing the jobs in concurrent, but executing the flyweight and the matrix configuration jobs on the same node (even in a serialized matter).
could you ellaborate how would your suggestion work in the practice?
I can see why could somebody argue that the svn plugin is doing what it was instructed to do (eg. wiping out any files/dirs from the checkout) but I think that it is rather unfortunate, that by default the checkout dir for the flyweight job to fetch the remote changes will use the same directory which the matrix configuration builds are residing in.