Git and Gerrit Workflows

Enforcing Manual & Automated Review

•  Branching and Workflow Review •  A Look at Gerrit •  The Gerrit Workflow •  Other Workflows •  Customizing Gerrit Workflow

Agenda

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

Maintain  related  sets  of  work  –  Work  on  older  releases  

trunk

rel-1.1

Branches  Have…  DuraDon  

trunk

feature Promote  and  

reDre  

Branches  Have…  Stability  

trunk

feature

rel-1.1

More  stable  

Less  stable  

Branches  Have…  Flow  of  Change  

trunk

feature

rel-1.1

Merge  down  

Promote  up  

Simple  to  Complex  

trunk feature

sandbox

rel

patch

custom

Workflow  Guides  the  Flow  of  Change  

trunk

task branch

svn merge git merge

A Look at Gerrit

Origins

Mondrian!

Rietveld!

Perforce-­‐centric  Google  internal  

Open  source  Subversion  

Android  ecosystem  Vibrant  community  

Community

User  Conferences  Hackathons  

Sponsors  Contributors  

Qualcomm  Motorola  Google  SAP  

SpoDfy  Yahoo  Nvidia  Samsung  

Repository Management

Key Features

Code Review

Access Control

Repository Management

Key Features

Code Review

Access Control

Repo  creaDon  HTTPS/SSH  

Repository Management

Key Features

Code Review

Access Control

Hierarchical  model  Granular  permissions  

LDAP  &  others  

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  

•  All changes are reviewed •  Dynamic review branches •  Review IDs group serial work •  Human voting •  Enforce CI on every commit

– Build system gets a vote!

Key Principles

Steps

Clone  • Gerrit  has  unusual  URLs  •  Should  clone  change-­‐id  hook  

Push  • Use  special  review  ref  •  Can  amend  exisDng  review  

Review  •  +1  to  like,  +2  to  approve  •  Build  result  

Submit  • Merge  through  UI  •  Commit  to  branch  

•  Web UI •  CLI / API •  Download patch •  Voting rights based on access control

– +/- 1 – +/- 2 – Verify

Review Options

Check  out  original  commit  

Amend  commit  with  new  work  

Push  again  

Rework

Each  change  has  a  unique  

ID  

All  amendments  preserved  as  patch  sets  

•  Even rejected changes are valuable •  Comments are often as important as the

code •  Can enforce ‘signed off by’

Etiquette

•  Best to see it in action •  Find a demo station

This is weird

Other Git Workflows

Fork and pull

Pull  request  Work  Fork    

Topic branches

30  

Merge  request  

Push  branch  Work  

Make  topic  branch  

Clone  

Mainline model

Push  frequently  

Push  to  trunk  

Work  locally  

31  

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  

git commit –am “task work” git push origin HEAD:refs/for/master <review, build, and publish in Gerrit>

Steps to Trunk

Customizing Gerrit Workflow

"  Defines when a change can be submitted

"  Default – One highest vote in

each category – No lowest votes in

any category

Submit Rules

Both:  Human +2!CI +1!  But  not:  Human -2!Or  CI -1!

"  Defines how a change can be submitted (per project)

"  Types – Fast forward only – Merge if necessary – Merge always – Cherry pick – Rebase if

necessary

Submit Types

"  Prolog – Logic programming

language – Often used in AI – Bit of a learning

curve

Custom Workflows

"   What’s possible –  Project-specific submit rules –  Replace default submit

rules –  Define when a commit is

accepted –  Override project submit type

"  Prolog-café fork embedded "  Prolog-shell provided for testing "  SWI-Prolog environment for debugging

Prolog in Gerrit

"  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 •  And indicates the submit criteria

Project-specific submit rules

"  Filters submit rules "  Runs up parent project hierarchy "  Mechanism for global admins to enforce

rules across all projects

Global submit filters

"  Write a submit_type predicate "  For any change indicate accepted submit

type "  Can include submit type filters

Custom submit type

"  Test submit_rule against a real change in Gerrit

"  Use test-submit rule

Testing submit rules

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