| Hello,
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?
|