Git and Gerrit Workflows Enforcing Manual & Automated Review
Agenda Branching and Workflow Review A Look at Gerrit The Gerrit Workflow Other Workflows Customizing Gerrit Workflow
Branching and Workflow Basics
Branches represent divergence. They confuse developers. They add complexity.
So why make a branch?
Maintain related sets of work Isolate unstable or custom code trunk feature
rel-1.1 trunk Maintain related sets of work Work on older releases
Branches Have DuraDon trunk feature Promote and redre
More stable trunk rel-1.1 Less stable feature Branches Have Stability
Branches Have Flow of Change Merge down rel-1.1 trunk feature Promote up
custom rel patch trunk feature sandbox Simple to Complex
Workflow Guides the Flow of Change task branch trunk svn merge git merge
A Look at Gerrit
Origins Android ecosystem Vibrant community Mondrian! Perforce- centric Google internal Rietveld! Open source Subversion
Community User Conferences Hackathons Sponsors Contributors Qualcomm Motorola Google SAP SpoDfy Yahoo Nvidia Samsung
Key Features Repository Management Access Control Code Review
Key Features Repository Management Access Control Repo creadon HTTPS/SSH Code Review
Key Features Repository Management Access Control Hierarchical model Granular permissions LDAP & others Code Review
Gerrit Workflow
The Gerrit Model Unreviewed changes isolated CI built into workflow
Android Repo coordinates 300+ repos Isolates patch authors from commi\ers Otherwise not as bad as it looks
Key Principles All changes are reviewed Dynamic review branches Review IDs group serial work Human voting Enforce CI on every commit Build system gets a vote!
Steps Clone Push Review Submit Gerrit has unusual URLs Should clone change- id hook Use special review ref Can amend exisdng review +1 to like, +2 to approve Build result Merge through UI Commit to branch
Review Options Web UI CLI / API Download patch Voting rights based on access control +/- 1 +/- 2 Verify
Rework Check out original commit Each change has a unique ID All amendments preserved as patch sets Push again Amend commit with new work
Etiquette Even rejected changes are valuable Comments are often as important as the code Can enforce signed off by
This is weird Best to see it in action Find a demo station
Other Git Workflows
Fork and pull Fork Work Pull request
30 Topic branches Clone Make topic branch Work Push branch Merge request
31 Mainline model Work locally Push to trunk Push frequently
Git Flow Uses several long lived branches Master Develop Staging Feature and release branches and tags 32
Gerrit Similar to topic branches with very narrow topics Really represents mainline model with continuous review ConDnuous Review The speedy picking up of unreviewed pending commits - Paul Hammant Every commit is reviewed Within minute or hours of compledon Before it hits trunk Ties review to code
Mainline model is built for condnuous delivery In pardcular have a mainline: a single branch of the project currently under development. Pre\y much everyone should work off this mainline most of the Dme. (Reasonable branches are bug fixes of prior producdon releases and temporary experiments.) Mar8n Fowler Steps to Trunk git commit am task work git push origin HEAD:refs/for/master <review, build, and publish in Gerrit>
Customizing Gerrit Workflow
Submit Rules " Defines when a change can be submitted " Default One highest vote in each category No lowest votes in any category Both: Human +2! CI +1! But not: Human -2! Or CI -1!
Submit Types " Defines how a change can be submitted (per project) " Types Fast forward only Merge if necessary Merge always Cherry pick Rebase if
Custom Workflows " Prolog Logic programming language Often used in AI Bit of a learning curve " What s possible Project-specific submit rules Replace default submit rules Define when a commit is accepted Override project submit type
Prolog in Gerrit " Prolog-café fork embedded " Prolog-shell provided for testing " SWI-Prolog environment for debugging
Project-specific submit rules " Stored in rules.pl in refs/meta/config branch Modify via Git commits " Sequence Gerrit provides a set of facts about a change Author, committer, message, etc. Provided in gerrit package Then calls rules.pl Submit_rule predicate Return value indicates whether change is submittable
Global submit filters " Filters submit rules " Runs up parent project hierarchy " Mechanism for global admins to enforce rules across all projects
Custom submit type " Write a submit_type predicate " For any change indicate accepted submit type " Can include submit type filters
Testing submit rules " Test submit_rule against a real change in Gerrit " Use test-submit rule cat rules.pl! ssh gerrit_host gerrit test-submit rule <change id> -s!
Example: Authors cannot +2 submit_rule(s) :-! gerrit:default_submit(x),! X =.. [submit Ls],! add_non_author_approval(ls, R),! S =.. [submit R].!! add_non_author_approval(s1, S2) :-! gerrit:commit_author(a),! gerrit:commit_label(label('code-review', 2), R),! R \= A,!,! S2 = [label('non-author-code-review', ok(r)) S1].! add_non_author_approval(s1,! [label('non-author-code-review', need(_)) S1]).!
Example: Only fast forward on release branches submit_type(fast_forward_only) :-! gerrit:change_branch(b), regex_matches('refs/heads/! release.*', B),!!.! submit_type(t) :- gerrit:project_default_submit_type(t)!
Thank You @rdefauw