Custom submit rules in rules.pl

[Magnus Bäck]

I'm looking into customizing the Prolog rules for determining whether a
change can be submitted, but in between the scarce documentation and my
limited Prolog skills, it turned out rather difficult.

I tried putting a rules.pl with simply

submit_rule(P).

in refs/meta/config of my test project and expected all changes to be
marked as submittable, but I didn't note any change in Gerrit's
behavior. Looking at ChangeControl.java I suspect it's because the
expected result isn't a boolean yes/no but rather a more intricate
structure listing which labels and ranges are okay. Trying

submit_rule(P) :- label(_, ok(_)).

instead effectively deleted all approval categories. Not just from the
set of approval categories available to me for scoring but the approval
categories displayed in the UI.

Can someone please shed some light on this? What's the expected result
of these predicates?

--
Magnus Bäck
ba...@google.com

[Shawn Pearce]

On Fri, Apr 13, 2012 at 09:45, Magnus Bäck <ba...@google.com> wrote:
> I'm looking into customizing the Prolog rules for determining whether a
> change can be submitted, but in between the scarce documentation and my
> limited Prolog skills, it turned out rather difficult.
>
> I tried putting a rules.pl with simply
>
>    submit_rule(P).
>
> in refs/meta/config of my test project and expected all changes to be
> marked as submittable, but I didn't note any change in Gerrit's
> behavior.

Leaving it like this means P is unbound, so we probably should have
failed everything rather than had no real change in behavior.

> Looking at ChangeControl.java I suspect it's because the
> expected result isn't a boolean yes/no but rather a more intricate
> structure listing which labels and ranges are okay. Trying
>
>    submit_rule(P) :- label(_, ok(_)).

This doesn't work either, as you said. Its functionally the same as
the first example you gave, except it tried to call that label/2
predicate which may wind up failing.

> instead effectively deleted all approval categories. Not just from the
> set of approval categories available to me for scoring but the approval
> categories displayed in the UI.

And that is why those got deleted, because label/2 probably failed so
we had no result.

> Can someone please shed some light on this? What's the expected result
> of these predicates?

The argument of submit_rule is actually an output, it needs to be a
submit term. Suppose we have only 1 label, and we always want it to be
OK:

submit_rule(P) :-
CR = label('Code-Review', ok(_)),
P = submit(CR).

I could have written this as:

submit_rule(submit(CR)) :-
CR = label('Code-Review', ok(_)).

Or even as:

submit_rule(submit(label('Code-Review', ok(_)).

But always allowing submit isn't useful, instead we want to also check
permissions and have possible alternatives. Something like this:

% A rejection from any reviewer, blocks submit.
submit_rule(submit(CR)) :-
max_with_block('Code-Review', -2, 2, reject(User)),
CR = label('Code-Review', reject(User)),
!.

% If a reviewer approved the change, its OK.
submit_rule(submit(CR)) :-
change_owner(Owner),
max_with_block('Code-Review', -2, 2, ok(Reviewer)),
not_same(Owner, Reviewer),
CR = label('Code-Review', ok(Reviewer)),
!.

% If the change owner marks it To Be Reviewed, OK.
submit_rule(submit(TBR)) :-
change_owner(Owner),
check_label_range_permission('TBR', 1, ok(Owner)),
TBR = label('TBR', ok(Owner)),
!.

% Permit valid reviewers to set the Code-Review label.
submit_rule(submit(label('Code-Review', S))) :-
max_with_block('Code-Review', -2, 2, S).

% Permit owners to set the TBR label.
submit_rule(submit(label('TBR', S)) :-
change_owner(Owner),
current_user(Owner),
S = need(1).

Remember, in Prolog "," works something like "boolean and" and the
interpreter keeps trying different alternate paths until it finds one
that works. The ! at the end of the first 3 rules are necessary to
prevent the interpreter from looking at the later cases that allow
using different labels. The above examples are completely untested.
:-)

[Magnus Bäck]

On Friday, April 13, 2012 at 13:22 EDT,
Shawn Pearce <s...@google.com> wrote:

[...]

> The argument of submit_rule is actually an output, it needs to be a
> submit term. Suppose we have only 1 label, and we always want it to
> be OK:
>
> submit_rule(P) :-
> CR = label('Code-Review', ok(_)),
> P = submit(CR).
>
> I could have written this as:
>
> submit_rule(submit(CR)) :-
> CR = label('Code-Review', ok(_)).
>
> Or even as:
>
> submit_rule(submit(label('Code-Review', ok(_)).

And in this simple case it would also be okay to replace _ with User or
any other variable, since we're not placing any additional conditions on
the variable (like we are in the subsequent examples)? Or would we still
be in trouble since the variable would be unbound?

> But always allowing submit isn't useful, instead we want to also check
> permissions and have possible alternatives. Something like this:
>
> % A rejection from any reviewer, blocks submit.
> submit_rule(submit(CR)) :-
> max_with_block('Code-Review', -2, 2, reject(User)),
> CR = label('Code-Review', reject(User)),
> !.

So, the interpreter will seek matches of max_with_block/4 and find
the one where the final argument is a reject term, and evaluate whether
there is a score equal to the minimum. If so, User will be bound to
whoever gave that score, and a submit term saying that the user in
question blocks the Code-Review label will be emitted?

> % If a reviewer approved the change, its OK.
> submit_rule(submit(CR)) :-
> change_owner(Owner),
> max_with_block('Code-Review', -2, 2, ok(Reviewer)),
> not_same(Owner, Reviewer),
> CR = label('Code-Review', ok(Reviewer)),
> !.

Okay, looks reasonable.

> % If the change owner marks it To Be Reviewed, OK.
> submit_rule(submit(TBR)) :-
> change_owner(Owner),
> check_label_range_permission('TBR', 1, ok(Owner)),
> TBR = label('TBR', ok(Owner)),
> !.

Yup.

> % Permit valid reviewers to set the Code-Review label.
> submit_rule(submit(label('Code-Review', S))) :-
> max_with_block('Code-Review', -2, 2, S).

Would this predicate actually be used with the current Gerrit
implementation that lets PatchSetPublichDetailFactory.call()
decide which labels a user is allowed to set?

> % Permit owners to set the TBR label.
> submit_rule(submit(label('TBR', S)) :-
> change_owner(Owner),
> current_user(Owner),
> S = need(1).

Doesn't this declare that if the current user owns the change,
the TBR label needs to be set?

[...]

--
Magnus Bäck
ba...@google.com

[Anjan Tummalapalli]

Hi, can someone please help me in writing prolog submit rule as below

- change can be submitted only when non committer approved

- Administrators group can self approve their own code

Thanks

Anjan

[Bassem Rabil]

You can use the Gerrit group "Change Owner" [1] to implement this by denying the change owner to set Code Review labels using your project permissions. You can check this discussion [2] for more information.

[1] https://gerrit-review.googlesource.com/Documentation/access-control.html#change_owner

[2] https://groups.google.com/forum/#!searchin/repo-discuss/Change$20Owner/repo-discuss/_TVvO1uP-R8/OOVhdv6UhucJ

Regards

Bassem

[Anjan Tummalapalli]

Hi Bassem,

Thanks for your quick reply.. Your solution is working for me as expected..

Thanks
Anjan

[Praveen Kumar]

Hi, can someone please help me in writing prolog submit rule as below

- change can be submitted only when default reviewer approves (Default reviewer for a change will be added while pushing it to review from command line) 

Thanks

Praveen

On Monday, March 16, 2015 at 5:27:48 PM UTC+5:30, Bassem Rabil wrote:

[Saša Živkov]

On Wed, May 20, 2015 at 8:26 AM, Praveen Kumar <prave...@gmail.com> wrote:

Hi, can someone please help me in writing prolog submit rule as below

- change can be submitted only when default reviewer approves (Default reviewer for a change will be added while pushing it to review from command line) 

 

Gerrit doesn't know about a "default reviewer" and cannot differentiate reviewers by how they were added (command line or UI).

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Narendra Choudhary]

I have to make the rule so that No Change Owner can give +2 for any projects including the Adminstrator. how would i do the same i am using the Gerrit version 2.9.4

[Edwin Kempin]

On Sun, Mar 13, 2016 at 5:53 AM, Narendra Choudhary <choudhar...@gmail.com> wrote:

I have to make the rule so that No Change Owner can give +2 for any projects including the Adminstrator. how would i do the same i am using the Gerrit version 2.9.4

You can't do this with submit rules. Submit rules can only control when a change becomes submittable (which makes the Submit button on the change screen appear).

Submit rules don't have any influence on who can approve, aka give +2 on a change. What you can do is, to ignore any +2 vote of the change author when computing the submittability of the change, see https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#NonAuthorCodeReview

 

On Friday, April 13, 2012 at 11:45:02 AM UTC-5, Magnus Bäck wrote:

I'm looking into customizing the Prolog rules for determining whether a
change can be submitted, but in between the scarce documentation and my
limited Prolog skills, it turned out rather difficult.

I tried putting a rules.pl with simply

    submit_rule(P).

in refs/meta/config of my test project and expected all changes to be
marked as submittable, but I didn't note any change in Gerrit's
behavior. Looking at ChangeControl.java I suspect it's because the
expected result isn't a boolean yes/no but rather a more intricate
structure listing which labels and ranges are okay. Trying

    submit_rule(P) :- label(_, ok(_)).

instead effectively deleted all approval categories. Not just from the
set of approval categories available to me for scoring but the approval
categories displayed in the UI.

Can someone please shed some light on this? What's the expected result
of these predicates?

--
Magnus Bäck
ba...@google.com

--

[vista...@gmail.com]

Hi,Pearce

For help 

How can I configure for that first reviwer must vote +1 first and then the second can vote +2 and sumit in rules.pl?    and that apply to specific branch in change

Thank you very much!

[Sharath Gupta]

I have a minimal knowledge in Prologs and Gerrit. I have a project in Gerrit 2.11 with Owners plugin installed. I need to write rules.pl such that "Change is submittable only if one of the owners in OWNERS file gives a code review+2 along with default submit rule". Please help.

I came across a sample rules.pl below but could not get the purpose of it. Can someone please explain. 

submit_rule(S) :-
  gerrit:default_submit(D),
  D =.. [submit | Ds],
  findall(U, gerrit:commit_label(label('Code-Review', 2), U), Approvers),
  gerrit_owners:add_owner_approval(Approvers, Ds, A),
  S =.. [submit | A].

 

Thanks

Sharath