3

I want to automate our build processes.

We have 30+ configurations, each with a different SVN branch. Ideally, I would want to avoid having to create 30 separate Jenkins jobs, due to maintenance effort and risk of human error.

This is what "multi-configuration project" in Jenkins was designed for, but unfortunately Jenkins doesn't support using the configuration matrix axis in the SVN URL.

I also cannot build using parameterized build, because Jenkins will not allow the variables to be used in the local checkout paths (variables in URLs work fine, but they always end up going to a directory called ${BRANCH} (literal).

At the end of the day, I would like to be able to check out https://domain.ext/something/${BRANCH}/ and save it to /some/path/${BRANCH}. Even better if this is done in a way that leaves me able to take advantage of Jenkin's built-in SCM features (e.g. polling).

How can I make Jenkins understand what I'm trying to achieve?

Johan Dahlin
  • 21,541
  • 5
  • 35
  • 52
Salieri
  • 742
  • 6
  • 17

3 Answers3

1

There's two ways of doing something along the lines of what you want that I can see. You could either add all the branches in a single project (via "add location" in the config), check them out to different directories and figure out "manually" what changed (or build everything). This could be integrated with the multi-configuration thing with your configuration axis being the different checkout locations, i.e. every configuration gets a different working directory through the parameter.

The other way would be not to tell Jenkins about the repository, but trigger builds manually (e.g. through an SVN commit hook) and check out the source as the first build step. Again this could be done as a multi-configuration project along similar lines as outlined above.

Lars Kotthoff
  • 101,128
  • 13
  • 187
  • 191
0

I ended up solving this by making Jenkins check out the SVN repository on so high level that it contained all the branches I needed. It's not an ideal solution though, because you lose time during builds for running 'svn update' on everything.

Salieri
  • 742
  • 6
  • 17
0

Had a similiar problem with smaller scale: Had to build trunk and a branch with same configuration, but different SVN path.

First attempt was using $SVN_BRANCH in the checkout URL and setting that with a string parameter. Worked well with manual usage, but didn't work with matrix job (as Aleksi already pointed out). All I was able to do with a matrix build was triggering the parametrized job as a follow up job which somehow looked ugly.

Now I ended up using the "Jobcopy Builder plugin": I de-activated my initial job and use it as a template. In the copy job I have a "copy job" build step which copies the deactivated job, replaces $SVN_BRANCH by the actual branch name (trunk or branches/some_branch) and activates those two jobs. Since I also checked the "overwrite" option, all job configurations are updated after running the "copy job" and the build history is preserved.

Florian Straub
  • 736
  • 8
  • 15