I thought of two things that might help if you have not done them already: 1) use the 'matrix tie parent' plugin and tie matrix jobs to the master server (I believe this ensures that a random master node is not chosen) 2) add '-Dhudson.model.WorkspaceCleanupThread.disabled=true' to the JENKINS_JAVA_OPTIONS in the jenkins config file, for example: (in linux the file is: /etc/sysconfig/jenkins) change from: JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true" to: JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Dhudson.model.WorkspaceCleanupThread.disabled=true" (restart jenkins)
I encountered workspaces being deleted mid-build and found that solution somewhere. It seems to have fixed that issue, maybe it will fix your issue as well. Thanks, Andy On Tuesday, January 29, 2013 8:34:48 AM UTC-7, Chris Withers wrote: > > Hi All, > > Has anyone else noticed that the parent job of a set of matrix builds > appears to still do anything before the "Build" section in the > configuration? > > This means that things like Delete workspace and Source Code Management > happen on the node running the parent job, even though I can't see when > you would ever want that and how it could be useful. > > Does anyone know why this is? > > In particular, when using a custom, shared workspace, this means that > the parent job of a matrix can stomp on other jobs that use the same > workspace. > > *sigh* not been a good day for matrix jobs and throttle-concurrent :-( > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
