| commit | 7c322d75aaa3447450c546ab22ac56da5e4c9263 | [log] [tgz] |
|---|---|---|
| author | Claudio Pacchiega <claudio.pacchiega@gmail.com> | Fri Dec 30 10:07:34 2016 +0100 |
| committer | Luca Milanesio <luca.milanesio@gmail.com> | Wed Feb 08 23:21:53 2017 +0000 |
| tree | 6ed55980680506297471920ad907978c0a726494 | |
| parent | 9910fea0897fd7b5a17a5b897716d76326cf765b [diff] |
Matching based rules in OWNERS config
Refactoring OWNERS file to be able to deal with matchers. Syntax has been
enhanced to be able to specify inherited matches blocks that can be
queried from rules.pl to understand if a change can be submitted based on
regular expression, exact match or suffix matching.
An example of the new OWNERS syntax:
inherits: false
owners:
- email1
- email2
matches:
- regex: .*/a*
owners:
- email3
- email4
- exact: Product.java
owners:
- email5
- email6
- suffix: .java
owners:
- email7
- email8
A possible rules.pl exploiting this can be written as follows:
In this case we impose that for every path defined by a matchers block
at least one of the associated owners must give a +2 to have the change
submittable
% default rule
submit_rule(S) :-
gerrit:default_submit(S).
% add extra label for every path P
submit_rule(submit(W)) :-
gerrit_owners:matcher_path(P),
findall(US,code_review_user(US),Approvers),
matcher_needed(Approvers,P,W).
% to get only matchers for that path
matcher_needed(Users,Path,W) :-
findall(US,needed_review_user(Path,US),NSL),
subtract(Users,NSL,Diff),
% if Users - Needed is unchanged this means we are missing at
% least one (!)
Diff == Users,
W = label(Path, need(_)).
code_review_user(US) :-
gerrit:commit_label(label('Code-Review', 2), user(U)),
user_string(U,US).
needed_review_user(Path,US) :-
gerrit_owners:matcher_owner(Path,user(User)),
user_string(User,US).
Change-Id: If5a389ad696bdec236f68af4bf1ee65f1d6d04faThis plugin provides some Prolog predicates that can be used to add customized validation checks based on the approval of ‘path owners’ of a particular folder in the project.
That allows creating a single big project including multiple components and users have different roles depending on the particular path where changes are being proposed. A user can be “owner” in a specific directory, and thus influencing the approvals of changes there, but cannot do the same in others paths, so assuring a kind of dynamic subproject access rights.
There are currently two main prolog public verbs:
add_owner_approval/3 (UserList, InList, OutList) appends label('Owner-Approval', need(_)) to InList building OutList if UserList has no users contained in the defined owners of this path change.
In other words, the predicate just copies InList to OutList if at least one of the elements in UserList is an owner.
add_owner_approval/2 (InList, OutList) appends label('Owner-Approval', need(_)) to InList building OutList if no owners has given a Code-Review +2 to this path change.
This predicate is similar to the first one but generates a UserList with an hardcoded policy.
Since add_owner_approval/3 is not using hard coded policies, it can be suitable for complex customizations.
There is a second plugin, gerrit-owners-autoassign which depends on gerrit-owners. It will automatically assign all of the owners to review a change when it's created or updated.
Create three symbolic links of the owners-owners, owners-common and owners-autoassign from the Gerrit source code /plugins directory to the subdirectories of this project.
Overwrite the Gerrit /plugins/external_plugin_deps.bzl with the one contained in the owners-common directory.
Then build the owners and owners-autoassign plugins with the usual Gerrit plugin compile command.
Example:
$ git clone https://gerrit.googlesource.com/plugins/owners $ git clone https://gerrit.googlesource.com/gerrit $ cd gerrit/plugins $ ln -s ../../owners/owners* . $ cp -f owners-common/external_plugin_deps.bzl . $ cd .. $ bazel build plugins/owners $ bazel build plugins/owners-autoassign
NOTE: the owners-common folder is producing shared artifacts for the two plugins and does not need to be built separately being a direct dependency of the build process. Its resulting .jar must not be installed in gerrit plugins directory.