| commit | cf928f1d78b675f1cec7039d8b345f810c8f48fe | [log] [tgz] |
|---|---|---|
| author | Edwin Kempin <ekempin@google.com> | Wed Apr 05 08:19:39 2023 +0000 |
| committer | Edwin Kempin <ekempin@google.com> | Wed Apr 05 08:53:31 2023 +0000 |
| tree | 9325b4791dc998e0b70b158cf058a895b8c06fb5 | |
| parent | 076e85045628941591b91c244a14cc4ffc57a599 [diff] |
Fix async change message that lists owned path on PostReview Support for posting the owned paths asynchronously when a code owner approval is applied was implemented by change I129e611af. At the moment the asynchronous message posting is triggered via the OnPostReview#getChangeMessageAddOn extension point. This extension point is intended to let plugins extend the change message that is posted by PostReview. Triggering the asynchronous message posting from this extension point has issues: * When the asynchronous message posting is triggered PostReview is not done yet, i.e. it didn't commit its updates the change meta ref yet. This means now there is a race between PostReview and the extension to update the change meta ref, which makes it likely that one of the updates fails due to LockFailure. * Since there is a race with updating the change meta ref, the order in which the messages are posted is undefined, but we want the PostReview message to be posted first. * If the update that is applied by PostReview fails with LockFailure, the whole operation, including the triggering of async message, is retried. This can lead to a situation where the change message with the owned path is created twice: 1. posting the async message succeeds, but the update from PostReview fails due to LockFailure (e.g. due to the problem described above, but LockFailures are also common due to other reasons) 2. PostReview is retried 3. posting the update from PostReview succeeds, but triggers the async message again which also succeeds (posting the async message is also retried on LockFailure, so it will likely succeed if the PostReview update is applied first) Fix this by not triggering the async posting of the owned paths from the OnPostReview#getChangeMessageAddOn extension point, but from the CommentAddedListener#onCommentAdded extension point which is only invoked after the PostReview update has been applied. Bug: Google b/276879211 Signed-off-by: Edwin Kempin <ekempin@google.com> Change-Id: I4d32542457de2f50b25eb7bf57f5f504720131ab
This plugin provides support for defining code owners for files in a repository.
If the code-owners plugin is enabled, changes can only be submitted if all touched files are covered by approvals from code owners.
For a detailed description of the plugin functionality please refer to the plugin documentation.
IMPORTANT: Before installing/enabling the plugin follow the instructions from the setup guide.
NOTE: The plugin documentation only renders correctly when the plugin is installed in Gerrit and the documentation is accessed via https:///plugins/code-owners/Documentation/index.html. If you want to read the documentation before installing the plugin, you can find it properly rendered here.
From the root of the gerrit repository.
bazel test //plugins/code-owners/web:karma_test
For testing the plugin with the Gerrit FE Dev Helper the command below builds
bazel build //plugins/code-owners/web:code-owners
ln -s bazel-bin/plugins/code-owners/web/code-owners.js polygerrit-ui/app/plugins/
and let the Dev Helper redirect from .+/plugins/code-owners/static/code-owners.js to http://localhost:8081/plugins/code-owners.js.