Maxime Guerreiro a63cc6eb70 Add SubmitRule extension point
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
2018-03-12 16:59:25 +01:00
2018-02-12 11:11:53 +01:00
2018-03-12 09:03:47 +09:00
2018-02-21 14:39:39 -05:00
2018-03-12 16:59:25 +01:00
2018-03-06 21:31:22 +00:00
2018-03-06 21:31:22 +00:00
2018-03-12 09:03:47 +09:00
2018-03-12 09:03:47 +09:00
2018-03-12 09:03:47 +09:00
2017-07-19 15:32:39 +09:00
2008-11-14 16:59:34 -08:00
2009-03-27 20:20:10 -07:00
2018-02-21 14:39:39 -05:00
2018-03-06 21:31:22 +00:00

Gerrit Code Review

Gerrit is a code review and project management tool for Git based projects.

Build Status

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.

Description
RETIRED, Gerrit as used by OpenStack
Readme 120 MiB