At the first Bay Area Hackathon in mid-2009, the topic du jour was "https://wiki.jenkins.io/display/JENKINS/Designing+pre-tested+commit[pre-tested commits]." As potential implementations of the concept were discussed over burgers from Brickhouse in downtown San Francisco, we realized as a group a few things: first, those burgers were delicious, but more importantly: pre-testing commits is very-SCM dependent and involves a lot of moving parts. One of the positive changes that came out shortly after the meet up was the support for "Concurrent Builds", allowing a job to be executed concurrently on different agents, a precursor to pre-tested commit support. Fervor for the pre-tested commit feature lowered as time went on, the feature being too dependent on the SCM itself was generally accepted as the reasoning behind the feature languishing.
Chances are the feature is in fact too large for Hudson to support alone. It requires Hudson, the SCM and likely a third tool to work in concert together to perform such a feat.
With Git, and the phenomenal code review tool Gerrit, and the Gerrit plugin by intrepid plugin developer, Jyrki Puttonen, pre-tested commits with Hudson, Git and Gerrit are possible.
For Git users more familiar with the distributed Git workflows, working with Gerrit should seem familiar. Gerrit has JGit, a Java implementation of Git embedded within it, along with an sshd stack, meaning Gerrit can masquerade as a "regular" Git remote repository. Developers can push and pull to the repository just as they can with any other Git repository (provided they have permissions of course). I won’t delve too much into using Gerrit specifically here, but the pre-tested workflow with Gerrit and Hudson would look something like this:
-
Dev creates a topic branch to work on a change
-
Code is written (and hopefully tested) and committed locally
-
Dev pushes commit(s) to Gerrit
-
Hudson job (set to Poll SCM) picks up the patch, runs the job and marks it as "+1 Verified" or "-1 Fails"
-
If the job fails or is unstable, the change should be reworked or corrected (typically with git-rebase(1))
-
If Hudson says the change is good to go, it can be cherry-picked or pulled directly from Gerrit.
For example:
To learn more about Gerrit, check out the project page on Google Code; information on the Gerrit plugin can be found on the wiki.
About the Author
|
R. Tyler Croy
R. Tyler Croy has been part of the Jenkins project for the past seven years. While avoiding contributing any Java code, Tyler is involved in many of the other aspects of the project which keep it running, such as this website, infrastructure, governance, etc. |