Git and Gerrit Workflows. Enforcing Manual & Automated Review

Size: px

Start display at page:

Download "Git and Gerrit Workflows. Enforcing Manual & Automated Review"

Gavin Higgins
6 years ago
Views:

1 Git and Gerrit Workflows Enforcing Manual & Automated Review

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

3 Branching and Workflow Basics

4 Branches represent divergence. They confuse developers. They add complexity.

5 So why make a branch?

6 Maintain related sets of work Isolate unstable or custom code trunk feature

7 rel-1.1 trunk Maintain related sets of work Work on older releases

8 Branches Have DuraDon trunk feature Promote and redre

9 More stable trunk rel-1.1 Less stable feature Branches Have Stability

10 Branches Have Flow of Change Merge down rel-1.1 trunk feature Promote up

11 custom rel patch trunk feature sandbox Simple to Complex

12 Workflow Guides the Flow of Change task branch trunk svn merge git merge

13 A Look at Gerrit

14 Origins Android ecosystem Vibrant community Mondrian! Perforce- centric Google internal Rietveld! Open source Subversion

15 Community User Conferences Hackathons Sponsors Contributors Qualcomm Motorola Google SAP SpoDfy Yahoo Nvidia Samsung

16 Key Features Repository Management Access Control Code Review

17 Key Features Repository Management Access Control Repo creadon HTTPS/SSH Code Review

18 Key Features Repository Management Access Control Hierarchical model Granular permissions LDAP & others Code Review

19 Gerrit Workflow

20 The Gerrit Model Unreviewed changes isolated CI built into workflow

$authors from commi\ers Otherwise not as bad as it$

21 Android Repo coordinates 300+ repos Isolates patch authors from commi\ers Otherwise not as bad as it looks

22 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!

23 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

24 Review Options Web UI CLI / API Download patch Voting rights based on access control +/- 1 +/- 2 Verify

25 Rework Check out original commit Each change has a unique ID All amendments preserved as patch sets Push again Amend commit with new work

26 Etiquette Even rejected changes are valuable Comments are often as important as the code Can enforce signed off by

27 This is weird Best to see it in action Find a demo station

28 Other Git Workflows

29 Fork and pull Fork Work Pull request

30 30 Topic branches Clone Make topic branch Work Push branch Merge request

31 31 Mainline model Work locally Push to trunk Push frequently

32 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

33 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

34 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>

35 Customizing Gerrit Workflow

36 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!

37 Submit Types " Defines how a change can be submitted (per project) " Types Fast forward only Merge if necessary Merge always Cherry pick Rebase if

38 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

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

40 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

41 Global submit filters " Filters submit rules " Runs up parent project hierarchy " Mechanism for global admins to enforce rules across all projects

42 Custom submit type " Write a submit_type predicate " For any change indicate accepted submit type " Can include submit type filters

43 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!

44 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]).!

45 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)!

46 Thank

Creating a Patch. Created by Carl Heymann on 2010 Sep 14 1

Creating a Patch. Created by Carl Heymann on 2010 Sep 14 1 Created by on 2010 Sep 14 1 1. Starting a Patch To create a patch, and get it through the review process and into a main branch of a project, you can follow the following steps: Clone the project if you