Code Reviews with Gerrit

1. Code Reviews with Gerrit Mateusz Szczap mobile.de (eBay) Confitura 2013, Warszawa

2. Why Gerrit • Frustrated with Atlassian Crucible, too long to create a review • Sometimes patch needs to be created manually as a file and uploaded via web interface • Engineering Support can automate a lot for us, e.g. Jenkins integration • Precommit code reviews can improve code quality

3. Gerrit Review = Git Push • To create a review you normally push to Gerrit Git repository. • All your team members would get an email...

4. Gerrit Task Automation • Allows automation of mundane tasks • Good for technical people that like automation. Us?

5. Gerrit SSH Commands • Common user ssh commands

6. Gerrit Git Mirror • Gerrit is a (Gated) Git Repository Mirror http://en.wikipedia.org/wiki/Mirror_test (Self-Awareness Test)

7. Gerrit Basics • Reviews only for new commits (not in git remote repository yet) • An approval and verification needed for a review to be merged to the remote git repository

8. Gerrit Basics • Pre-commit code reviews (hard for hot fixes and critical prod bugs that need to be fixed immediately) allows to detect bugs, code styles issues before they reach a branch or master • Once review is complete a change can be merged or a review can be abandonded. • Gerrit can be set up to be a mirror of an existing git repository or a repository on it‘s own. The former is less intrusive.

9. Gerrit @ mobile.de https://review.corp.mobile.de

10. Gerrit Basic User Setup Click here

11. Gerrit Basic User Setup

12. Gerrit Basic User Setup

13. Review Demo p

14. Change Id • Change Id uniquely identifies this particular review • Important to track Patch Sets • Required at the end of commit message, can be automated with git hook scripts (later on this)

15. Gerrit Patch Sets • One review can include a multiple Patch Sets before that change is merged to a respective feature or master branch. • One can perform comparisons between patch sets

16. Gerrit Verify and Review • Verify – user tested the code (+1,0,-1). Jenkins can be a user as well (unit tests). • Review - user performed code review (+2, +1, 0, -1, -2) • At least one person needs to approve the code for the changed to be published (e.g. merged to the main git repository)

17. Review Commit

18. Commit Message Comments • You can comment on Commit Message

19. File Review • Double click to include review:

20. Gerrit Keyboard Shortcuts • You can use shortcuts in the web UI, list of them - ?. Useful is: [ or ] to navigate between files.

21. Gerrit Review Status • When you push a change to Gerrit a review will be created but the change will not be in target git repository (in case of mirroring).

22. Gerrit Review Publish & Submit • Normally a reviewershould just Publish Comments andonlythecreatorofthereviewshouldPublishandSubmit (e.g. merge) tothemaingitrepository. Leave for review creator unless he is on holidays, sick or agreed to merge the change.

23. Gerrit Review Submit • WhySubmitis so obscure? Why not merge? • Mergeisoneoptionofsubmit, itisconfigurable per Project via Gerrit Admin UI • Default: MergeIfNecessary

24. Local Gerrit Config • Vim .gitconfig • You can add multiple reviewers with –-reviewer switch or –cc (carbon copy). Usually team members • Each remote alias refers to a branch name • Submit a review with: git push m-1

25. Local Gerrit Config • Vim .gitconfig • You can add multiple reviewers with –review switch or –cc (carbon copy). Usually team members • Each remote alias refers to a branch name Gerrit magic, special refs/for notation

26. Local Gerrit Commit Hook • Normally each Gerrit Review to support Patch Sets requires an unique Change Id • scp -p -P 29418 review.corp.mobile.de:hooks/commit-msg .git/hooks/  • Will copy a git commit hook to a local git repo Here is our commit hook

27. Local Gerrit Commit Hook • Needs to be created for every project. Not nice. Better to use .git_templates, which are supported as of git 1.7.1 • Copy generated gerrit commit_hook there to ~/.git_template/hooks • New cloned projects will have commit hook out of the box • Old projects, do git init, this will copy git gerrit commit hook

28. Local Gerrit Commit Hook • In order to submit another Patch Set you have to amend the previous git commit. • git commit --amend. • Previously configured git commit hook will append the same Change Id • If you submit a new commit you will get an error message asking you to squash git commits or a new review will be created. You can always do that using git rebase -i • Git commit --amend called by some as git “hackery”

29. Gerrit Review Submit • Submit a review with: git push m-1 • On successful submit Gerrit will allocate a review id and show on the console url to gerrit review

30. JIRA integration • Gerrit review tasks as comments to JIRA tickets • If you specify a Jira ticket number, e.g. PMR-123 inside a git commit message a gerrit review url will be added as a comment to a Jira ticket

31. Jenkins integration • Jenkins becomes a reviewer that can add a verify +1 or -1 • Jenkins will try to build a branch with a contribution and run unit tests • Jenkins will prevent contribution from being merged when it does not build or when unit tests fail

32. Jenkins integration

33. Jenkins integration

34. Gerrit Tips & Gotchas • Precommit reviews, a review not in target repository but in „limbo“ state. • Merge immediately to branch, review later – one possibility but against Gerrit principles • Depending on the Submit strategy one has to either send the change alone to git or gerrit will do this • Review commits as quickly as possible no to block work flow • Catch up merges to your branch can complicate submitting patchsets (head no longer change itself)

35. Thanks! • It can be tricky to begin with but reaping benefits later is a pure pleasure (code quality) Gerrit site: • https://code.google.com/p/gerrit/ Questions: mateusz.szczap@gmail.com