1

I have a situation where a chain of Java projects in SVN need to be built for continuous integration. The projects can exist in multiple branches, and I want to perform CI builds on all of them. However, I would rather not have a different Jenkins project for each Java projects/SVN branch combination. What I have done is to create Jenkins projects that take the SVN branch as a parameter, and set up the project dependency chain, passing the branch parameter along. (I am using Ivy for this project, rather than Maven, so I don't have a plugin to do that for me.) I set up a chain kickoff job for each branch which defines the branch parameter and starts automatically several times each day.

PROS: This allows me to create a single Jenkins kick-off project for each branch, rather than the entire chain of projects.

CONS: The build happens on a schedule, rather than as a result of SVN polling. This means all the branches build multiple times a day, even if no changes have been made in that branch.

What I would like to happen ideally is have the kickoff project poll ALL the projects in the chain periodically, and build the chain if there are any changes. Is there a way to do that? Would it be as simple as specifying all the project locations in the kickoff project (using the branch parameter) and then specify polling as the build trigger?

cneff
  • 388
  • 6
  • 15
  • If you have access to SVN then you can configure Post Commit hook which will make SVN give all the info like the branch on which the commit happened. You can then use it to run the job. http://stackoverflow.com/questions/12794568/how-to-configure-git-post-commit-hook – NotAgain Dec 16 '14 at 02:18
  • Unfortunately, I don't have access to the Jenkins server in this corporate environment to set up support for the post commit hook. Thanks anyway for the good suggestion. – cneff Dec 17 '14 at 17:47

1 Answers1

2

If I understand correctly: you want to poll a number of SVN locations from your "kickoff" job, but you don't want your "kickoff" job to actually checkout all those SVN locations?

You can configure the "kickoff" job, give it all possible SVN locations (or a top-level location, such as /branches/ that will have all branches under it), and set the checkout depth to empty. Then configure SCM polling on this job. It will poll all SVN locations, but won't actually perform the lengthy checkout. Once SCM changes are detected, your kickoff job will start, and trigger the rest of your chain

Slav
  • 27,057
  • 11
  • 80
  • 104
  • That worked quite well, once I realized that each SVN location needed to check out to a unique subdirectory in my workspace. Before that it would always see a change, since the first locations revision data wouldn't match that of the last location. – cneff Dec 17 '14 at 17:46