Google Git
Sign in
gerrit / gerrit / a3e333d07cf04270235ef162a30d759f08c49db1
commita3e333d07cf04270235ef162a30d759f08c49db1[log] [tgz]
authorYoussef Elghareeb <ghareeb@google.com>Tue Sep 07 14:48:08 2021 +0200
committerYoussef Elghareeb <ghareeb@google.com>Tue Sep 07 16:40:38 2021 +0200
tree50dc92ecec9407f7074d39855abd30f8a623daec
parent18640041836197b9235143a24e3c19d1ccff1d55 [diff]
Fix StoreSubmitRequirementsOp for the Rebase submit type

StoreSubmitRequirementsOp is a BatchUpdateOp that is executed when a
change is about to be merged. For projects requiring a rebase upon
submission (e.g. if default submit type = RebaseAlways), the batch
update contains another RebaseSubmitStrategy#RebaseOneOp that creates an
additional patchset (the rebase patchset) which is then submitted. This
patchset is also inserted in the ChangeContext and becomes visible to
the StoreSubmitRequirementsOp.

Current implementation of StoreSubmitRequirementsOp used to create
ChangeData using the ChangeContext#getChange() parameter (which was just
updated by the rebase op). Trying to lookup ChangeData#currentPatchset
fails, because it loads patchsets from NoteDb but tries to find the
patchset with the ID of the one just inserted.

In this change, we update StoreSubmitRequirementsOp to create ChangeData
using the project/change IDs. Now requesting ChangeData#currentPatchset
succeeds but it returns the pre last patchset commit ID. This means that
in this situation, we will store submit requirement results in the
changes notes of the pre last patchset commit. This should be fine
though, since submit requirements will evaluate to the exact same
results for both commits. Additionally, the pre-last commit is the one
for which we displayed the submit requirement results of the last
patchset to the user before it was merged.

Alternatives considered:
* Make SR storage non-atomic, i.e. with a separate update after the
change is merged.
* Implement an ordering of batch update ops to enforce SRs storage op be
executed first. This will still imply storing SR results in the pre last
commit and should not be implemented for just this corner case: Our
batch update ops do/should not rely on ordering.

Bug: Google b/196271654
Change-Id: Ia3cd55a3c8693a1b96e8b70dc084af4650999e76
2 files changed
tree: 50dc92ecec9407f7074d39855abd30f8a623daec
  1. .settings/
  2. .ts-out/
  3. antlr3/
  4. contrib/
  5. Documentation/
  6. e2e-tests/
  7. java/
  8. javatests/
  9. lib/
  10. modules/
  11. plugins/
  12. polygerrit-ui/
  13. prolog/
  14. prologtests/
  15. proto/
  16. resources/
  17. tools/
  18. webapp/
  19. polymer-bridges
  20. .bazelignore
  21. .bazelproject
  22. .bazelrc
  23. .bazelversion
  24. .editorconfig
  25. .git-blame-ignore-revs
  26. .gitignore
  27. .gitmodules
  28. .gitreview
  29. .mailmap
  30. .pydevproject
  31. .zuul.yaml
  32. BUILD
  33. COPYING
  34. INSTALL
  35. Jenkinsfile
  36. package.json
  37. README.md
  38. SUBMITTING_PATCHES
  39. twinkie.patch
  40. version.bzl
  41. WORKSPACE
  42. yarn.lock
README.md

Gerrit Code Review

Gerrit is a code review and project management tool for Git based projects.

Build Status Maven Central

Objective

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.

Documentation

For information about how to install and use Gerrit, refer to the documentation.

Source

Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.

Reporting bugs

Please report bugs on the issue tracker.

Contribute

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.

Getting in contact

The Developer Mailing list is repo-discuss on Google Groups.

License

Gerrit is provided under the Apache License 2.0.

Build

Install Bazel and run the following:

    git clone --recurse-submodules https://gerrit.googlesource.com/gerrit
    cd gerrit && bazel build release

Install binary packages (Deb/Rpm)

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

Use pre-built Gerrit images on Docker

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.