| As you well know Paul, I don't have a Git-Jenkins setup (yet), but off the top of my head, if I was concerned about the network latency and space consumption of cloning a full git repo across the network for every Jenkins job execution, I would approach my setup as follows:
(1) First, on the Jenkins build server, setup a single bare repo mirror of the remote repo. There are a number of ways to mirror a git repo such as executing a 'git remote fetch --all' on the mirror side or adding a post-commit hook on the remote side to push all commits to the mirror as they come in, so just google git repo mirroring and pick a method that works best for you.
(2) For your Jenkins workspace clone operation one or more of the git clone operations that gives the fastest clone and is suitable for a Jenkins workspace clone (see --local, --shared, --reference, --no-checkout, --single-branch and --depth options), some of which will give you a minimal, hard-link-no-copy or a shallow single-branch clone that might be useful only to use as a short-lived skeleton repo useful only for a for a Jenkins build of a single commit snapshot of a working copy.
HTH, Kieran On Jun 21, 2012, at 7:34 PM, Paul Hoadley wrote: 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?
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|