| commit | df0b65f4f5a638e24a67b7fa6ed86ada8e628978 | [log] [tgz] |
|---|---|---|
| author | Jacek Centkowski <geminica.programs@gmail.com> | Sun Jan 07 10:40:57 2024 +0100 |
| committer | Jacek Centkowski <geminica.programs@gmail.com> | Mon Jan 22 08:43:42 2024 +0100 |
| tree | 2227ac139a4e9403dd9673cfb8a83a1d1a855c6d | |
| parent | ea7531bef7283cc7a24ccbb9a0b4e0cc1b5ffa8c [diff] |
Bubble up OWNERS file parsing errors
Problem:
The OWNERS file adheres to the YAML standard. In cases where it is not
parseable (due to simple errors like incorrect indentation or missing
`:`, etc.), the error message is logged and ignored. To discover what
went wrong, one needs access to the error_log.
Solution:
Ensure that information about broken OWNERS files reaches Gerrit's UI
through the following steps (bottom-up):
1. Do not catch `IOException` in the
`ConfigurationParser.getOwnersConfig` function; let it be caught by
the caller.
2. Catch it in the `PathOwners.getOwnersConfig` function. However, it is
too broad to be further conveyed (there are other `IOException`
instances that shouldn't be confused with OWNERS file issues).
Therefore, re-throw it as the newly introduced
`InvalidOwnersFileException`.
3. The OWNERS content is cached; therefore, the
`InvalidOwnersFileException` can only be thrown during cache value
load. As such, it is wrapped into an `ExecutionException`. Catch it
and unwrap it back to `InvalidOwnersFileException` if that was the
cause, leaving all other cases handled as they were before.
The `InvalidOwnersFileException` is re-thrown up to the callers.
4. The following handling was applied to `PathOwners` callers:
- In the owners-autoassign plugin, it is caught and logged at the
warning level (not much can be done there as there is no UI for it).
- In `OwnersStoredValues` (used by the owners plugin prolog predicate
to get the OWNERS file content), it is re-thrown as a runtime
exception. `PrologRuleEvaluator` nicely handles it and shows the
`gerrit~PrologRule` label with the status `ERROR`.
- In `OwnersSubmitRequirement`, it is caught and returned as
`RULE_ERROR`, represented as the `owners~OwnersSubmitRequirement`
label with the status `Error`. The following message is displayed
when hovering over it:
Invalid owners file: OWNERS, in project: [repo-name], on branch [branch-name]
- In the `GetFilesOwners` REST API endpoint, it is caught and thrown
as a `ResourceConflictException` (the same way as in `code-owners`).
When called, the following response is returned to the caller:
HTTP/1.1 409 Conflict - Invalid owners file: OWNERS, in project: [repo-name], on branch [branch-name]
The handling of `InvalidOwnersFileException` is confirmed in the
integration tests, but it was also verified manually.
Bug: Issue 310420006
Change-Id: I4425e6ede74332832de39c0769549c7e917e67fc
This 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.
This plugin is built with Bazel and two build modes are supported:
To build the plugin, issue the following command:
bazel build :all
The output is created in
bazel-bin/owners/owners.jar bazel-bin/owners-autoassign/owners-autoassign.jar bazel-bin/owners-api/owners-api.jar
To execute the tests run:
bazel test //...
This project can be imported into the Eclipse IDE:
./tools/eclipse/project.sh
Create symbolic links of the owners and owners-autoassign folders and of the external_plugin_deps.bzl file to the Gerrit source code /plugins directory.
Create a symbolic link of the owners-common plugin to the Gerrit source code 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 . $ ln -s ../../owners/owners-autoassign . $ ln -s ../../owners/owners-api . $ ln -sf ../../owners/external_plugin_deps.bzl . $ cd .. $ ln -s ../owners/owners-common . $ bazel build plugins/owners 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.
The output is created in
bazel-bin/plugins/owners/owners.jar bazel-bin/plugins/owners-autoassign/owners-autoassign.jar
To execute the tests run:
bazel test owners-common:test
This project can be imported into the Eclipse IDE:
Add the plugin name to the CUSTOM_PLUGINS (and in case when you want to run tests from the IDE to CUSTOM_PLUGINS_TEST_DEPS) in Gerrit core in tools/bzl/plugins.bzl file and run:
./tools/eclipse/project.py