===Basics=== Each project can have their own rules.pl together with a submit_rule predicate. It seems you can also have a submit_filter predicate that takes in the previously set results and modify them, ie, in all-projects or something like that, but I haven't tested that.
The submit_rule takes one 'argument' and you need to fill it in with the form submit(label(name,status),label(name,status),...) You can name the labels anything you want, but if your users should be able to score them, they need to be created in the database like the old review categories. (Anyone know if that is correct?)
I haven't found a way to set a review-score through the prolog scripts, nor a good way to communicate to users, but I guess it's not really intended for that.
So what can you do? Lots of data is exposed: commit message, all the files that have been modified, author, etc etc. This is pretty well documented in the 2.2.2 release notes.
*Warning*: Once you create a rules.pl file, the old legacy rules will not be used!
== Example 1+1 = 2 == The rule allows submit if the accumulated score of the review is at least 2. Ie, one +2 or two +1's.
%% rules.pl. %% Allow submit if there is a total of +2 in review 'scores' (accumulative) %% This file is an example to learn about prolog submit checkers %% :- package user.
%% Result returned from submit_label should be something like %% submit(label(name,status),label(name,status),...) %% Status can be either ok(_), reject(_), need(_) or impossible(_) %% ok() and reject() takes a user id as their argument, but I dont know how that is used.
sum_list(, 0). sum_list([H | Rest], Sum) :- sum_list(Rest,Tmp), Sum is H + Tmp.
check_min_label(Category, Min, P) :- findall(X, gerrit:commit_label(label(Category,X),_),Z), sum_list(Z, Sum), ( Sum >= Min -> P =.. [label,Category,ok(Who)] ; P =.. [label,Category,need(Min)] ).
% This is the function that will be invoked by gerrit. We call the check_plus2 function and returns a function submit(...) % which gerritalways expects. (See gerrit_common.pl:133) submit_rule(P) :- check_min_label('Code-Review', 2, HasPlusTwo), P =.. [submit, HasPlusTwo].
=== How to test === Upload a change for review, then keep pushing changes to rules.pl until it does what you want. A simple re-load on the project page will directly use the updated rules.pl
(There is a built-in interpreter, but I haven't been able to properly load both gerrit_common.pl together with a rules.pl (Shawn?). I did manage to test rules locally by adding %Test submit_rule x_can_submit(SubmitRule, S) :- submit_rule(Tmp), Tmp =.. [submit | Ls], ( is_all_ok(Ls) -> S = ok(Tmp), ! ; S = not_ready(Tmp) ).
is_all_ok(). is_all_ok([label(_, ok(__)) | Ls]) :- is_all_ok(Ls). is_all_ok(_) :- fail. to my rules.pl)
but that won't work once you try to use the gerrit builtin predicates.
On Fri, Feb 3, 2012 at 11:43 AM, Markus Stauffiger <mar...@4eyes.ch> wrote: > Ok, thank both of you for your tipps! :) > > On 2 Feb., 18:09, Martin Fick <mf...@codeaurora.org> wrote: >> On Thursday, February 02, 2012 06:42:56 am marksta wrote: >> >> > Dear gerrit group >> >> > We would like to give every developer review permissions >> > for +1 and I would like gerrit to merge as soon as there >> > are two +1. >> >> I think that if you made the CR category only range up to >> +1, then you could remove submit from all users except for a >> special hook user, and then make the comment-added hook >> perform the submit when it sees the second +1. >> >> -Martin >> >> -- >> Employee of Qualcomm Innovation Center, Inc. which is a >> member of Code Aurora Forum > > -- > To unsubscribe, email repo-discuss...@googlegroups.com > More info at http://groups.google.com/group/repo-discuss?hl=en