We have a team of roughly ~8 devs who regularly work on the same feature over the course of a 3 week sprint. It isn't quite pair programming, but in our current workflow devs regularly push up incomplete code for a colleague to complete. This worked fine before we introduced Gerrit, but now our commits need to represent chunks of test-passing, complete, logical functionality, and so the model breaks.

My only idea is to have everybody push up to a separate, untracked branch up until the functionality is ready for review, then squash everything into commits that make sense and push up. Is there another Gerrit-ized workflow that could work?

I know this is a widely discussed topic on Google Groups, and that there has recently been some discussion of Gerrit topic reviews, but I wanted to see if there is anybody out there using Gerrit in this way, and what the suggested workflow would be.

  • When the developers are pushing code for their colleagues to complete, did they know what colleague would be working on it next, or was it just pushing unworking code on a branch to a central repo, for whomever to pick up?
    – pcurry
    Jun 11 '13 at 20:38
  • They typically know exactly who is going to be working on it.
    – Bacon
    Jun 13 '13 at 18:40
  • 1
    Have they configured their development boxes so they could pull from each other? That would enable them to share code without going through Gerrit. They would have to be diligent in their history management, which might be a point of friction.
    – pcurry
    Jun 13 '13 at 20:28

If you want to share a change over Gerrit without publishing it, then the following workflow might work:

  • (no1) push the change to refs/for/*
  • (no2) get the change by checking it out (command can be found at the patchet panel in Gerrit)
  • (no2) make code modification, amend it and push it back

After pushing any changes to Gerrit, the local branch can be reset, since every change can be checked out from Gerrit. Also consider keeping the local branch updated by resetting it:

  • git fetch
  • git reset --hard <remote_branch>

In this way merge commits will be eliminated easily (merge commits should not be pushed).

If the team is working on the same feature then the commit should be rebased more often before push. (Gerrit abandon the push if the commit needs rebase) use git rebase -p <remote_branch>'to resolve it.

This workflow has only one issue - each push will trigger several jenkins jobs (hope). I think by now it is hard to tell jenkins not to run tests for a particular change. Gerrit trigger plugin only consider files and branches.

If a trigger could examine the commit message or the topic name first, then it would be easy to force Jenkins not to run by adding tag to the commit message like [WIP]. If you agree with that please vote for the feature request: https://issues.jenkins-ci.org/browse/JENKINS-19019 and check this commit message template suggestion: https://softwareengineering.stackexchange.com/a/203484/91685


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.