a63cc6eb70
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
39 lines
1.3 KiB
Java
39 lines
1.3 KiB
Java
// Copyright (C) 2011 The Android Open Source Project
|
|
//
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
// you may not use this file except in compliance with the License.
|
|
// You may obtain a copy of the License at
|
|
//
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
//
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
// See the License for the specific language governing permissions and
|
|
// limitations under the License.
|
|
|
|
package com.google.gerrit.server.rules;
|
|
|
|
import com.google.gerrit.extensions.annotations.Exports;
|
|
import com.google.gerrit.extensions.config.FactoryModule;
|
|
import com.google.gerrit.extensions.registration.DynamicSet;
|
|
|
|
public class PrologModule extends FactoryModule {
|
|
@Override
|
|
protected void configure() {
|
|
install(new EnvironmentModule());
|
|
bind(PrologEnvironment.Args.class);
|
|
factory(PrologRuleEvaluator.Factory.class);
|
|
|
|
bind(SubmitRule.class).annotatedWith(Exports.named("PrologRule")).to(PrologRule.class);
|
|
}
|
|
|
|
static class EnvironmentModule extends FactoryModule {
|
|
@Override
|
|
protected void configure() {
|
|
DynamicSet.setOf(binder(), PredicateProvider.class);
|
|
factory(PrologEnvironment.Factory.class);
|
|
}
|
|
}
|
|
}
|