I've dealt with this by having multiple upstream jobs and using the shell to figure out which job triggered the real job and using that to apply the minor tweaks. I do this for a couple of different situations but the most interesting deals with automatic merging of git branches. I needed to have different behaviors for my daily merge and an hourly merge. The daily merge compiles each of the component branches before merging... So it can take hours to run (depending on how many branches are weing merged). The hourly just does a code merge and stops. For the hourly and daily merges I have a very simple job with some scheduling and something to set up a properties file with the configuration for the downstrean build. I usually extract this information by using the xml api to get the build metadata and parse it using xmlstarlet[1] to extract the values I need.
I've also done this with matrix builds.... but I've dealt with all the differences in my build scripts (Ant). I can then use the different axes values to do various things. For all the builds these are used to setup various keys and credentials needed for the finished application. And in some cases there are extra changes like use of other bits of code (copied over from another location depending on build parameters) or extra build steps. I'm a huge fan of bash and ant which I've used extensively over the past 7 years to automate all sorts of build tasks. I actually prefer doing a lot of my build logic for Jenkins using bash/ant and just store it along with my project in source control so I can keep records of the changes to the build process over time. The scm checkout logic usually lives in Jenkins (using either the git or svn components... though lately I've been using bash for this as well since my source checkout rules have become a wee bit more complicated than the scm plug-ins can deal with). But you can get a long way with just stock Jenkins and the parameterized trigger plug-in. :-) Ben [1] http://xmlstar.sourceforge.net/ On Jul 6, 2012 10:14 AM, "Sami Tikka" <[email protected]> wrote: > > Bram de Jong kirjoitti 6.7.2012 kello 11.00: > > > On Tue, Jun 19, 2012 at 8:50 PM, Sami Tikka <[email protected]> wrote: > >> So, you have a number of jobs that are mostly identical but there's a > >> little bit that should work differently for them. > >> > >> To me this sounds like a perfect case of multi-configuration job. > >> https://wiki.jenkins-ci.org/display/JENKINS/Building+a+matrix+project > >> > >> Essentially, Jenkins will run your job a number of times but each run > >> will have a different value for an environment variable. You can then > >> vary the build behavior based on the environment variable. > > > > This actually sounds good for us? > > > > * Is there any way to do inter-matrix-job dependencies - or possibly a > > way to trigger another build for some of the matrix points? > > AFAIK, no. You can configure a matrix job to execute some configurations > first, but not real dependencies. > > > * Will jobs share the same checkout on disk or will a different > > checkout be created for each point in the matrix? > > Each matrix configuration acts like it was a job of it's own. Each > configuration checks out the source separately. > > > * Can some points in the matrix be hardwired to certain nodes? (for > > example mac <-> windows) > > Yes, a configuration axis can also be a slave name or label. > > -- Sami
