A Hudson/GitHub build process that works

I’m a huge fan of Hudson, and have been since I discovered it. The biggest issue I’ve had with it is that the Git plugin just isn’t very good.

The situation has improved lately, with Andrew Bayer making significant improvements. With the features he’s added, reasonable and non-hacky workflows are no possible.

After some experimentation, this is what we’ve settled on at SimpleGeo:

  1. Developers work on whatever branches they choose.
  2. The work is reviewed and merged to the pending branch when it passes.
  3. Hudson polls the pending branch. Changes are merged to master (in the repo on Hudson), and the build is performed.
  4. If the build was successful, the result is pushed to the master branch of the repo on GitHub.

This works extremely well with GitHub’s Organizations and forking mechanism. Everyone at SimpleGeo has read-only access to all our repos. Each repo is owned by a particular team, and all team members have read-write access. Because of how Organizations work, any member can fork a private repo, and it will stay private — they don’t even need to be on a paid account. If someone wants to contribute to another team’s code, they just fork it, commit to their fork, and send a pull request to the owners. From there, the changes get reviewed and integrated into the pending branch, which triggers Hudson.

2010/08/27
, ,
Previously On Atomized:
⚛

Discussion

Great post Ian. I like the flexibility of being able to work on any branch you want, and push it when it’s ready.

Andrew Mager
2010/08/28

You’re welcome. =)

Andrew Bayer
2010/08/31

[...] found a few posts on the topic, but nothing related to AppEngine. Then I came across PubSubhubbub and saw how their [...]

Continuous Integration with Google AppEngine | Flomosa Company Blog
2010/10/19

Participate