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.

  • Should I use Jenkins CI server for deploying WAR file to Tomcat?
  • How to change home directory of Jenkins?
  • How to configure a jenkins job to send mail if a SCM commit
  • Spread load evenly by using ‘H * * * *’ rather than ‘5 * * * *’
  • How to dynamically pick a git branch to use in Jenkins build
  • To where should I point the VCS root of TeamCity?
  • 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?

  • Hudson git error ssh
  • How to add my current project to already existing github repo
  • Call GitHub API with Travis to build Tag
  • Git Moving Files into Folders
  • How can I create a Docker image based on a git tag in the public Registry?
  • Egit ssh problems
  • 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.

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