On 22/06/2012, at 9:04 AM, Paul Hoadley wrote: I'm looking at moving some projects from Subversion to Git. We use Jenkins as a build server. I'm interested to know some broad details about the WO-Git-Jenkins setups that others are using.
In the past, we've used Subversion repositories that are somewhere in the middle of the range from "monolithic" (where absolutely all of your code is in one repo) to "atomic" (where it's basically one Eclipse project per repo). For example, an "application" repo might contain three Eclipse projects: one app, and a couple of frameworks, say. I had intended to basically continue this arrangement with the move to Git, mostly because it's pretty easy to just dump out an entire repo with git-svn. But I've already run into at least the following problems:
1. Unlike Subversion, where I can pick a point in the tree from which to begin the checkout (say, FooProject/FooApp), with Git I need to clone the whole repo into the Jenkins workspace. I suspect I can work around this with some changes to my workspace setup script.
2. Related, say I'm building Jenkins jobs FooApp and FooFramework from within the FooProject repo—now I'm cloning the entire repo into the workspace of each of those jobs.
Neither of these are show-stoppers, but it seems messy. I _could_ get around this by having a strict single-project-per-repo policy—but then repo proliferation becomes an issue, and I no longer have the convenience of grouping related projects together in one repo.
Can anyone share their broad approach to these issues?
A month has passed, and I'm still only marginally closer to a satisfactory solution here.
There seems to be no simple way around the issue of cloning the entire repo for each Jenkins job, though the Git plugin at least allows you to specify "Included Regions", which is a regex with which you can nominate, say, 'FooApplication/.*' so that commits only to FooApplication trigger builds for the FooApplication job. _However_, I'm not convinced this works reliably. I'm currently debugging a situation where pushing commits to multiple Eclipse projects within the one repo is triggering only the _first_ Jenkins job. Obviously that can be disastrous if the project dependency is the other way around. (I haven't got to the bottom of it yet—something like that is happening, though I can't prove it's the fault of Jenkins.)
Trying to build on multiple branches is very awkward. My workspace setup script (derived from the original Subversion-based script that Mike Schrag wrote years ago) is not branch-aware, and the best way to make it so is not obvious. (The main problem is that, as with the original script, it copies frameworks into the workspace based on the project's .classpath. There's no way to denote in the .classpath that I want the 'develop' branch of FooFramework.framework, and then there would only be convention to rely upon to find that as a Jenkins job anyway. How is all this best generalised?) So at the moment, I add an extra build step that deletes the frameworks copied over from their 'master' branch projects, and copies over those frameworks from the required branch.
Seriously, I'd love to hear from anyone else who is doing any of this—especially building multiple branches of the same projects from Git repos, using Jenkins and the Git plugin (or any other plugin). Does anyone have anything they can share? Has anyone looked at Atlassian's Bamboo?
|