|
||||||||
|
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.
Our builds are volatile, with a constantly changing process and new data files (and types) added and old ones removed. If you know of a process that can guarantee the same level of effective clean with the same cost/benefit ratio (i.e. 100% guaranteed bug free cleaning and zero work in maintaining it) then I would be interested to know what that is.
We do use a branch parameter in the client build spec. But unless you also use a different workspace root then any unused branches in the client spec are removed by Perforce. Have you found a way around that? That would be really useful to know.
The branches we want to build change frequently. If we had to set up new jobs all the time it would be a constant maintenance headache. Using a build parameter means fewer jobs and lower maintenance / fewer mistakes. The jobs are run in parallel, as I said in my original post - and because they are effectively the same job we can use the "throttle concurrent builds" plug-in to control the resource usage. We can see which branches are running as we have overridden the default naming convention (as Jenkins allows) so you can see what the important parameters are for each job that is executing.
I don't mean to be argumentative for the sake of it, but the bottom line is we now have a solution that works perfectly for our needs. If anyone else wants to do the same thing then you can use my solution, or if you know of a better way please share. Thanks.