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? > > > -- > Paul Hoadley > http://logicsquad.net/ > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
