Gerrit submit rule is a set of conditions that needs to be fulfilled before change can be submitter (read merged) to given branch. By default there are only two simple conditions:
- Verified +1 (V+1)
- Code Review +2 (CR+2)
First one means that change don’t break the build (or project integrity). This step can (and it should) be automated using, a continuous integration system like (jenkins with gerrit trigger plugin). Automation here will save tons of men hours spent on reviewing code that doesn’t compile and/or break unit/integration/system tests.
Second one (Core Review +2) means that somebody from the team spent some time on reviewing and understanding the change. And this particular person didn’t found issues in it and thinks that this change is ready for production.
This set of rules seams to be reasonable and will be sufficient for “most” of the projects. But it has some flows, indirectly build in.
First of all there is no condition on the person that is giving the CR+2. In this case, change author can submit his own change, because there is no condition that would block him from doing so.
Also if you would like to enforce more strict review rules for given project. eg. at least two CR+2 are required to submit a change. You will probably end up with ‘internal convention’ not something that can be enforced automatically by Gerrit.
Of course, one can say that those two cases are exotic. Yes, in a way they are. But my point here is that default Gerrit submit rules are OK for (let say) 90% of projects. Projects that fallow Android OpenSource Project review principles (they can even don’t know that they fallow them ;)).
What is with rest 10%?
No, they are not forgotten by Gerrit… but they have a bit harder live at the beginning.
Why it is harder? Because of Prolog.
Gerrit gives you a tool for defining your own Submit Rules per project. But the entry point is (I would personally say) high.
To define your own Submit Rules one need to learn Prolog programming language, then understood Gerrit Prolog API and finally define such custom Submit Rules per each project in refes/meta/config branch.
This is awesome! Show me a tool that have such flexibility build in, ready to use … and it is free? Yes, entry level is high but, come on, this is one time investment and you are set for (almost) a live time… 😉
But maybe we could do something better here? Maybe we are missing something here… maybe we are not looking abstract enough.
Let me compare code review process to standard build process. In both cases you have some steps that need to be accomplished before you move to next mile stone. In build first of all source code files need to be compiled, same goes for test source files in next step. After that tests are run, and when they pass successfully, project can be packaged and put into production.
Same goes for the review process. First of all change need to be verified (compiled and tested) then team members are looking on code and if they found issues with it, change must be reworked. If not, it can be “packaged” to “production” I mean, merged to branch.
If we use such approach, then maybe instead of writing code for review rules, we could have a configuration file. Why not put the configuration and convention over Prolog code?
Provided that we would have such configuration syntax in place, then we could define set of rules that will verify the configuration file. Then wring UI for generating such config file shouldn’t be so hard (compared to generating Prolog code).
OK, lets finish with those “what if’s” because there is noting to wishful thinking. Why? Because we already implemented such ‘configuration over Prolog code’ approach in CollabNet. This is what we called Quality Gate wizard.
It contains two key parts:
- Quality Gate Gerrit Backend plugin – that adds special Prolog fact capable of understanding XML based configuration parameter.
- Quality Gate RCP Wizard – Eclipse based desktop application (build into GitEye app) that allow you use one of 15 predefined rules, define new submit and edit existing one. Then upload that to Gerrit. Everything from your desktop, no command line, text editor or git command is involved in that process.