|
I'm pondering how best to use Hudson to support our parallel development efforts. For some of our projects, there are multiple parallel development streams. Each development stream is using a branch in our SCM. While the branch does contain code differences, building any particular branch is identical except for the SCM path.
My first thought was to use a parameterized build where the branch name is a parameter. Then my SCM configuration could be "$/project/branches/{BRANCH_NAME}". However, then I would only have SCM polling for one branch (the default parameter value). I considered a matrix build, but my understanding is that the SCM polling would still poll once and then the job would build each combination of parameters. Thus, in my situation, if my main SCM path changed, all branches would be built. Instead, I'd prefer to see multiple jobs, each configured for a separate branch. While I can simply copy and modify one job to another, I'll end up with dual maintenance (or triple, or more!). Is there some other option I'm not thinking of? |
|
Trinition wrote:
> I'm pondering how best to use Hudson to support our parallel development > efforts. For some of our projects, there are multiple parallel development > streams. Each development stream is using a branch in our SCM. While the > branch does contain code differences, building any particular branch is > identical except for the SCM path. > > My first thought was to use a parameterized build where the branch name is a > parameter. Then my SCM configuration could be > "$/project/branches/{BRANCH_NAME}". However, then I would only have SCM > polling for one branch (the default parameter value). > > I considered a matrix build, but my understanding is that the SCM polling > would still poll once and then the job would build each combination of > parameters. Thus, in my situation, if my main SCM path changed, all > branches would be built. > > Instead, I'd prefer to see multiple jobs, each configured for a separate > branch. While I can simply copy and modify one job to another, I'll end up > with dual maintenance (or triple, or more!). > > Is there some other option I'm not thinking of? > was a bug not being able to resolve parameters when specifying a tag - maybe it has been solved in the meantime). This didn't add complexity to my management of jobs, since I already had a good complexity, since I have 5/6 different jobs for each project (because they are multi-stage etc). I resolved to having the config.xml for all the jobs to be auto-generated with templates and an Ant script. I've not yet blogged about that, but you can checkout the templates and the ant script from https://kenai.com/hg/tidalwave~other, and see all my jobs (configuration are publicly readable) at http://hudson.tidalwave.it/hudson/. The project jrawio_2.0 is a branch of jrawio - in fact you'll see that it's currently broken, while jrawio is fine. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people [hidden email] --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
Thanks, Fabrizio. I hadn't considered out-of-band solutions where I created/modified the job configuration from my own master template outside of Hudson altogether!
|
| Powered by Nabble | See how NAML generates this page |
