GitHub, Gerrit, Hudson(Jenkins) workflow

Question

I'm just getting started using GitHub, Gerrit, and Hudson(Jenkins) together. And I need some thoughts on workflow.

We'd like to use GitHub as our main remote repo. We'd like to use Gerrit primarily for code reviews, but also for build triggers in Hudson.

At the moment, though, I'm having some trouble thinking through the workflow for this and would like to hear what others have done themselves. Thoughts?

Answer 1

I haven't directly used Gerrit, but I like the idea of intermediate and specialized repo between:

• your developer's repos
• the central GitHub remote repo

So you need to determine what you want to publish in the remote GitHub repo:

• code to be reviewed (meaning a local Gerrit webapp would pull the GitHub code to examine)
• code that has been reviewed (meaning you publish first your commits to Gerrit, and after code review, you push them to GitHub)

The second workflow is closer to what Google Android Projects follows with Gerrit.

In both cases, an intermediate local repo for Gerrit to examine is needed.

Answer 2

We are using github, gerrit and jenkins (successor of hudson). We tie it together with redmine for bugtracking.

Prior to gerrit, we were using github as the primary development repository and developers had commit access. Now that we have gerrit running, github is only used as our publish repository and only the gerrit user has access to push to github.

workflow:

1. developer checks out source from github.
2. developer makes changes.
3. developer pushes to gerrit.
4. gerrit sends change notice to jenkins for integration test.
   • jenkins pulls changes directly from gerrit git server.
   • on pass, jenkins adds +1 to gerrit review, passes review to other developers.
   • on failure, jenkins adds -1 to gerrit review
   • pass/fail status pushed to redmine
5. other developers review change, approve (+2)
6. gerrit commits changes to github repository.
   • github hook notifies redmine of updates.
   • redmine pulls changes from github, parses commit messages for ticket information.
7. developer fetchs changes from github ... back to 2. [EDIT]: we switched to pulling directly from gerrit. Github remains as a mirror for pulling production sources.

Missing pieces:

1. piece to tie gerrit review to/from bug tracking.