GitHub, Gerrit, Hudson(Jenkins) workflow

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.

  • Jenkins - Dont build for specific commiter or commit message
  • How to automate docker deployment based on GitHub webhook?
  • How do I get just the branch from a Git command?
  • CI in GIT: how to revert multiple commits of a feature
  • Can we tell CruiseControl.NET to ignore source control timeout errors?
  • Hudson git plugin won't clone repo on Linux
  • 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?

  • How to setup Jenkins with HA?
  • Git, fatal: The remote end hung up unexpectedly
  • Is this a suggested process for using GitHub with a team?
  • LaTeX math in github wikis
  • How can I specify the latest commit version in Gradle
  • Permission denied when cloning git repository
  • 2 Solutions collect form web for “GitHub, Gerrit, Hudson(Jenkins) workflow”

    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.

    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.


    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.
    Git Baby is a git and github fan, let's start git clone.