| commit | 2670b9d71c827fa5a72e3156ca6fd012dd7c8f88 | [log] [tgz] |
|---|---|---|
| author | Edwin Kempin <ekempin@google.com> | Thu Nov 24 10:30:27 2022 +0100 |
| committer | Edwin Kempin <ekempin@google.com> | Tue Nov 29 10:19:21 2022 +0100 |
| tree | 5a6223370c15ccfa78df8ece3426c0840edf44e1 | |
| parent | 97adb2c2a3343426cfa2af668601bc8a53fb3149 [diff] |
Refactoring: Merge PostReviewCopyApprovalsOp into PostReviewOp
The change updates that are done in the PostReview REST endpoint are
performed by several BatchUpdateOps, amongs others we have these ops
that are executed in this order:
1. PostReviewOp:
Amongst other things PostReviewOp:
a) updates approvals on the change
b) posts a change message on the change (e.g. to inform about the
updated approvals)
These steps are executed in this order: first a) then b).
2. PostReviewCopyApprovalsOp:
Copies updated approvals that have been applied on an outdated patch
set to follow-up patch sets if they are copyable (to know which
approvals have been updated it reads the updated approvals from
ChangeUpdate, this means PostReviewCopyApprovalsOp must be executed
after PostReviewOp has updated the approvals).
Now we want to inform users via a change message about the approvals
that are copied to follow-up patch sets by PostReviewCopyApprovalsOp.
Instead of posting a separate change message for this in
PostReviewCopyApprovalsOp we rather want to extend the existing change
message that is posted by PostReviewOp. This means the copying of the
approvals to follow-up patch sets (what is currently done by
PostReviewCopyApprovalsOp) must happen before PostReviewOp posts the
change message, but after the PostReviewOp updated the approvals:
1. update approvals on the change (currently done by PostReviewOp)
2. copy updated approvals that have been applied on an outdated patch
set to follow-up patch sets if they are copyable (currently done by
PostReviewCopyApprovalsOp)
3. post a change message on the change inform about the updated
approvals and the approval copying to follow-up patch sets (currently
done by PostReviewOp)
To resolve this problem PostReviewCopyApprovalsOp is merged into
PostReviewOp, so that the copying of the approvals to follow-up patch
sets becomes a step in between updating the approvals on the change and
posting the change message.
This change is a pure refactoring change, which means that it doesn't
change any behaviour. It's only a preparation that allows us in a
follow-up change to include the approvals that are copied to follow-up
patch sets into the change message.
Release-Notes: skip
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I72d78ada62ff891603f540ea1114561245570fb3
Gerrit is a code review and project management tool for Git based projects.
Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.
Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer.
For information about how to install and use Gerrit, refer to the documentation.
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Please report bugs on the issue tracker.
Gerrit is the work of hundreds of contributors. We appreciate your help!
Please read the contribution guidelines.
Note that we do not accept Pull Requests via the Github mirror.
The Developer Mailing list is repo-discuss on Google Groups.
Gerrit is provided under the Apache License 2.0.
Install Bazel and run the following:
git clone --recurse-submodules https://gerrit.googlesource.com/gerrit
cd gerrit && bazel build release
The instruction how to configure GerritForge/BinTray repositories is here
On Debian/Ubuntu run:
apt-get update && apt-get install gerrit=<version>-<release>
NOTE: release is a counter that starts with 1 and indicates the number of packages that have been released with the same version of the software.
On CentOS/RedHat run:
yum clean all && yum install gerrit-<version>[-<release>]
On Fedora run:
dnf clean all && dnf install gerrit-<version>[-<release>]
Docker images of Gerrit are available on DockerHub
To run a CentOS 8 based Gerrit image:
docker run -p 8080:8080 gerritcodereview/gerrit[:version]-centos8
To run a Ubuntu 20.04 based Gerrit image:
docker run -p 8080:8080 gerritcodereview/gerrit[:version]-ubuntu20
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.