a63cc6eb70
The creation of custom rules to control the submitability of changes presents major disadvantages: the rules must be written in Prolog, which is harder to master than other options, and not as modular as it could be. By providing an interface that plugins can use to implement custom presubmit rules, these disadvantages should disappear: Gerrit plugins have full access to the core systems, but also to external resources. Everything that was possible with Prolog should be possible, and easier to achieve. Plugins can implement this interface and react however they want: a plugin can for instance define a Prolog rule evaluator, while an other hardcodes the rules in the Java code. With this implementation, all the plugins implementing SubmitRule are called. If a plugin doesn't want to participate in the voting process, it just has to return an empty collection. An other way to implement a similar process would have been to use the project's config file to enable or disable each plugin, by hand. It is more explicit: we know what is enabled and where, but it is also harder to maintain: plugins wouldn't work out of the box. What format should be used to declare the config? Also, this is not retro-compatible with the Prolog rules engine, which is enabled by default _if_ a file named rules.pl exists. A similar change was proposed by Saša Živkov during the Gerrit Hackathon 2016, cf [1] and the change Ifd5d2a in particular. The main difference between our changes lies in the design. The purpose of this change (here) is to allow the use of multiple validation plugins, so that one can handle the OWNERS file while an other checks the Labels, for instance. I truely believe plugin composition is important for the pre submit rules, as it allows smaller modular plugins while allowing greater power to the end user. Unfortunately, it also makes it very hard, if not impossible, to correctly handle dynamically determined submit types. Thus, Prolog will be able to change it (for backward compatibility reasons) but new plugins won't have this option for now. (The issue here being that multiple plugins may not come to an agreement on what submit type should be used). Our SubmitRule interfaces look similar, with two slight differences: - We don't encourage throwing exceptions. Plugins should handle this case. - We don't pass a second argument "SubmitRulesFlag" It is also important to note that the second commit of this change introduces SubmitRequirements, allowing plugin authors to improve the interactions with the users, replacing the strange error messages like "Needs label: Author-Is-Maxime" with explanatory messages. The third commit introduces a change that is only required because of plugin composition: a change can only be submitted if all the plugins agree that it can be. In the third change, Saša Živkov implemented the LabelFunctions in Java. I think this is a good idea and plan to do the same. [1]: https://gerrit-review.googlesource.com/q/topic:non-prolog-submit-rules-gh16 Change-Id: Ic0731321eb9d182ddbfa27d7c08eaeea9f3155e5
Gerrit Code Review
Gerrit is a code review and project management tool for Git based projects.
Objective
Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.
Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer.
Documentation
For information about how to install and use Gerrit, refer to the documentation.
Source
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Reporting bugs
Please report bugs on the issue tracker.
Contribute
Gerrit is the work of hundreds of contributors. We appreciate your help!
Please read the contribution guidelines.
Note that we do not accept Pull Requests via the Github mirror.
Getting in contact
The IRC channel on freenode is #gerrit. An archive is available at: echelog.com.
The Developer Mailing list is repo-discuss on Google Groups.
License
Gerrit is provided under the Apache License 2.0.
Build
Install Bazel and run the following:
git clone --recursive https://gerrit.googlesource.com/gerrit
cd gerrit && bazel build release
Install binary packages (Deb/Rpm)
The instruction how to configure GerritForge/BinTray repositories is here
On Debian/Ubuntu run:
apt-get update & apt-get install gerrit=<version>-<release>
NOTE: release is a counter that starts with 1 and indicates the number of packages that have been released with the same version of the software.
On CentOS/RedHat run:
yum clean all && yum install gerrit-<version>[-<release>]
On Fedora run:
dnf clean all && dnf install gerrit-<version>[-<release>]
Use pre-built Gerrit images on Docker
Docker images of Gerrit are available on DockerHub
To run a CentOS 7 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-centos7[:version]
To run a Ubuntu 15.04 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-ubuntu15.04[:version]
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.