Thanks for the suggestions, Sami. I'll reply in-line: On Friday, July 6, 2012 7:10:36 PM UTC+2, sti wrote: > > a) Instead of having the 3 jobs with git branch as parameter, make several > sets of 3 jobs. Each set has a fixed branch they build from. If creating > the jobs is too much manual work, you can automate the creation of the > jobs, either with a script or with a Jenkins job. >
This would explode the number of jobs. We still all use the "All jobs" view when looking at Jenkins, and I would hate getting the team into using Views as default. We're a small team of 5 people with about 90 jobs, which is small enough to everyone keeping an eye on them in one view. b) Try to use Parameterized Trigger plugin to trigger downstream builds. > Pass a "predefined parameter" in the form of BRANCH_TO_BUILD=$GIT_BRANCH. > Apparently the git plugin sets GIT_BRANCH, I just do not know if that is > available in the Parameterized Trigger, but I'm fairly sure it should be. > Yeah, this is already working. The problem is configuring the downstream jobs' SCM triggering without messing anything up. > c) Make a new plugin that supports picking up the git branch and passing > it on. > As above, passing the branch along is not a problem. > d) Install Groovy post build plugin and use a groovy script to dig up the > branch and pass it on. > > Again, passing the branch value from the upstream job works fine. It's making sure that the downstream build both * builds the branch $BRANCH_TO_BUILD when passed from upstream, and * monitors all branches for SCM changes If there was something like a "Groovy *pre* build plugin" where I could decide the above logic before building, that would be perfect. Otherwise, I think I'm left with extending the Jenkins Git Plugin with the option of overriding configured Branch Specifier with some environment variable (OVERRIDE_GIT_BRANCH_SPECIFIER) that I can pass from upstream.
