[RFC] Gerrit Submit Rules: shall we make the rule engine pluggable?

[lucamilanesio]

Hi Gerrit Community,

at the moment the only way to define Gerrit Submit rules is through Prolog (see [1]) and the only way to add a non-Prolog custom logic is through the MergeValidationListener interface (see [2]).

There are situations however where there are no Prolog skills available in the company (or they are not evenly spread across the org) and even though a scriptable solution could be put in place using Groovy, Scala or other scripting language ... that would allow only to provide implementation for a merge validation listener, which wouldn't provide a great user-experience.

My proposal is: as we abstracted the plugins from the language used, why don't we do the same with the Prolog rules?

This could be achieved using a staged approach:

a) Refactor [1] in order to introduce a provider pattern

b) Implement [1] as core-plugin that provides the Prolog support for rules.pl

c) Implement new syntax for rules using other languages such as Scala or Groovy, extending the scripting providers

What do you think?

I remember that Saša talked about something similar a while ago ... but I couldn't recall what level of pluggability he had in mind.

Luca.

[1] https://gerrit.googlesource.com/gerrit/+/refs/heads/master/gerrit-server/src/main/java/com/google/gerrit/server/project/SubmitRuleEvaluator.java

[2] https://gerrit.googlesource.com/gerrit/+/refs/heads/master/gerrit-server/src/main/java/com/google/gerrit/server/git/validators/MergeValidationListener.java

[Edwin Kempin]

On Mon, Jun 13, 2016 at 2:45 PM, lucamilanesio <luca.mi...@gmail.com> wrote:

Hi Gerrit Community,

at the moment the only way to define Gerrit Submit rules is through Prolog (see [1]) and the only way to add a non-Prolog custom logic is through the MergeValidationListener interface (see [2]).

There are situations however where there are no Prolog skills available in the company (or they are not evenly spread across the org) and even though a scriptable solution could be put in place using Groovy, Scala or other scripting language ... that would allow only to provide implementation for a merge validation listener, which wouldn't provide a great user-experience.

My proposal is: as we abstracted the plugins from the language used, why don't we do the same with the Prolog rules?

This could be achieved using a staged approach:

a) Refactor [1] in order to introduce a provider pattern

b) Implement [1] as core-plugin that provides the Prolog support for rules.pl

c) Implement new syntax for rules using other languages such as Scala or Groovy, extending the scripting providers

What do you think?

I remember that Saša talked about something similar a while ago ... but I couldn't recall what level of pluggability he had in mind.

This is exactly what Sasa was working on [1], only for c) only a Java implementation was foreseen.

[1] https://gerrit-review.googlesource.com/#/q/topic:non-prolog-submit-rules-gh16 

 

Luca.

[1] https://gerrit.googlesource.com/gerrit/+/refs/heads/master/gerrit-server/src/main/java/com/google/gerrit/server/project/SubmitRuleEvaluator.java

[2] https://gerrit.googlesource.com/gerrit/+/refs/heads/master/gerrit-server/src/main/java/com/google/gerrit/server/git/validators/MergeValidationListener.java

--
--
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.

[Luca Milanesio]

On 13 Jun 2016, at 13:50, Edwin Kempin <eke...@google.com> wrote:

On Mon, Jun 13, 2016 at 2:45 PM, lucamilanesio <luca.mi...@gmail.com> wrote:

Hi Gerrit Community,

at the moment the only way to define Gerrit Submit rules is through Prolog (see [1]) and the only way to add a non-Prolog custom logic is through the MergeValidationListener interface (see [2]).

There are situations however where there are no Prolog skills available in the company (or they are not evenly spread across the org) and even though a scriptable solution could be put in place using Groovy, Scala or other scripting language ... that would allow only to provide implementation for a merge validation listener, which wouldn't provide a great user-experience.

My proposal is: as we abstracted the plugins from the language used, why don't we do the same with the Prolog rules?

This could be achieved using a staged approach:

a) Refactor [1] in order to introduce a provider pattern

b) Implement [1] as core-plugin that provides the Prolog support for rules.pl

c) Implement new syntax for rules using other languages such as Scala or Groovy, extending the scripting providers

What do you think?

I remember that Saša talked about something similar a while ago ... but I couldn't recall what level of pluggability he had in mind.

This is exactly what Sasa was working on [1], only for c) only a Java implementation was foreseen.

[1] https://gerrit-review.googlesource.com/#/q/topic:non-prolog-submit-rules-gh16 

Yes, exactly the one I was talking about :-) I remember he started working on it during the Hackathon.

Having a Java implementation would make the Groovy or Scala step much easier.

Happy to join the effort with reviews and contributions !

Luca.