Allows a job to check out sources from multiple SCM providers.
This plugin is more of a proof-of-concept than a robust and fully functional component. It does work in my particular build environment, and is meant to serve as a demonstration of what might be possible with more work. It was inspired by issue #7155 requesting multiple repository checkouts for Mercurial similar to what is possible with the Subversion plugin. It's currently implemented as a plugin, but if enough people find it useful, I think the idea would work better in the Jenkins core.
We are a small team and have been using Subversion which has been adequate for our needs. However, I wanted to experiment with distributed VCS systems, so I tried using Mercurial for a medium-sided update to one of our projects and enjoyed it very much. Everything went great until I got to the Jenkins build part. Our projects are small to mid-sized and are usually structured like:
The in-house library is built by an upstream job, but the 3rd-party dependencies are checked out as part of the build. With subversion, we could check each one out individually, and initially I thought this is what I wanted for Mercurial as well. However, quite often we have the entire source for the library checked in, but the build really only needs a single dll or jar. Since Mercurial doesn't support partial clones, it now seems better to leave these in subversion since they're rarely changed and we can check out just the parts needed during a build.
I googled for solutions, but the ones I found all seemed to have limitations compared to the working and adequate subversion solution:
In the SCM section of the Jenkins job configuration screen, choose 'Multiple SCMs'. You'll then see a drop-down list of the available SCM plugins which can be configured similar to the way build steps are configured for a freestyle job. When chosen, each SCM plugin will present its normal set of configuration options.
Make sure each SCM checkout is done in a separate sub-directory of the workspace to avoid conflicts between the SCM providers. If using Mercurial, this option is hidden in the 'Advanced' section, so don't forget to configure it.
If changing the SCM provider for an existing job, I recommend wiping out the workspace.
The implementation was easier than I originally expected, and learned a lot along the way. It basically serves as a proxy between Jenkins and existing SCM plugins. The job configuration panel uses a hetero-list similar to the build steps section. That way, all the configuration options are handled by the real SCM plugins. For the actual SCM functions, it pretty much just iterates over each configured SCM plugin and forwards the request. There is some messiness in dealing with changelogs, but it's not too bad.
Skip to end of metadata Go to start of metadata