Jenkins: best way to build a project with sub projects

Question

We have a project with two subprojects in the same SVN repository. For example:

svn://ip/svn/ trunk/subproject1
svn://ip/svn/ trunk/subproject2

The build for project should include results of builds of both subprojects. To make our build faster, I want to run build of subproject1 only if SVN was changed respectively (in the svn://ip/svn/ trunk/subproject1). Similarly for subproject2

What is the best way to do it? Can I do it with a single job? How should I define build triggers in this case?

Or I need to define 3 jobs: one for each subproject or one for each project?

Any help will be appreciated! Best regards, Michael

Answer 1

There are various ways you can achieve this using Jenkins.

1. The multi-SCM plugin will allow - as the name suggests - to include multiple source repositories in a single job.

2. You can define n jobs which trigger each other (i.e. have a dependency on each other). You can find this under Build Triggers > Build after other projects are built.

3. There is also the option of a master job controlling the downstream jobs. You'll find this option under Post-build Actions > Build other projects.

With regard to build triggering, you can use the poll SCM option. It's not the most efficient method but your options may be limited with SVN rather than Git.

I just noticed you also mentioned collating results from all builds - you can achieve this either by having a single job or by using the option aggregate downstream test results under Post-build Actions.

Ultimately, you need to be clear on your build strategy. It sounds to me that you want to ensure that nothing is broken if a change has been made to either sub-project. I'm not sure how well the multi-SCM plugin copes with the concept of polling multiple repositories so you may need to factor that in.

I think I've given you a few options to try out; let me know how you get on.

Answer 2

This is an old thread (18 months) but a few days ago the Jenkins multijob plugin has released a new version that incorporates an option that allows triggering a build only when scm changed since last build:

This is the Build only if SCM changes.

There is also an option to force the build regardless of this option.