Update git submodules

* Update plugins/replication from branch 'stable-3.0'
  to f52f142403c2d8a11b4bb8c821854cd714f9faa1
  - Merge branch 'stable-2.16' into stable-3.0
    
    * stable-2.16:
      ReplicationIT: fix flakiness of shouldReplicateNewBranch
      ReplicationIT: remove dependency of ReviewDb/NoteDb
      ReplicationIT: Add a test that HEAD update is replicated
      ReplicationIT#shouldReplicateNewBranch: Create branch on local project
      ReplicationIT: Don't swallow exceptions on failed repository operations
      ReplicationIT: Fix typo in method name
      AdminApi: Reintroduce return value of methods
      Store replication tasks instead of ref-update events
      ReplicationIT: Don't swallow exceptions on failed repository operations
      ReplicationIT: Add explicit test for replication of new branch
      ReplicationIT: Change test method name to reflect actual operation
      Allow AdminApiFactory to be replaced dynamically
    
    Adapt project creation to use ProjectOperations.
    
    Change-Id: I3d9cd916be200f1935be2a60d9a4e715e4b859a3
    
  - ReplicationIT: fix flakiness of shouldReplicateNewBranch
    
    shouldReplicateNewBranch() should compare the target branch with
    the source SHA1 and not with the target.
    
    Comparing two SHA1 on the target repository is flaky because
    the two replication events may come at different times.
    
    Change-Id: Icfc4da705bc07805e881faea517984fb2c9abe09
    
  - ReplicationIT: remove dependency of ReviewDb/NoteDb
    
    Tests need to be independent on the underlying changes storage
    and thus make assertions of the expected replication tasks and
    the associated refs regex.
    
    Change-Id: I1e645339888deef609670ca3e58517a159e93b2b
    
  - ReplicationIT: Add a test that HEAD update is replicated
    
    Change-Id: I140a63933fe50bc6d5ec109fe6d46a2371a89f1e
    
  - ReplicationIT#shouldReplicateNewBranch: Create branch on local project
    
    The test creates the branch directly on the target project, which
    defeats the point of the replication test since the branch is not
    actually getting replicated there.
    
    Fix it to create the branch on the local project, which was the
    original intention when the test was added in change I67aa8b4ae.
    
    Change-Id: I517f3f49241207861e2f5158c08f6193a63d8916
    
  - ReplicationIT: Don't swallow exceptions on failed repository operations
    
    Change I02d8cda0a undid the improvements in the tests that were
    done by change I0f0caca03.
    
    Rework the tests to reintroduce those improvements.
    
    Change-Id: I812674325bb6756fbcdc3d9674fc8ca69c8f3c82
    
  - ReplicationIT: Fix typo in method name
    
    Change-Id: I5a4d468f18cd50009132c0c516f3475906e04c7f
    
  - AdminApi: Reintroduce return value of methods
    
    Prior to change Ie760bf3e1 all the methods of GerritSshApi returned
    a boolean value. After that change, they all return void.
    
    Removing the return value breaks classes that extend GerritSshApi and
    expect to be able to invoke the superclass implementation and get the
    status.
    
    In change I6566f8671 the return value of createProject was changed
    back to boolean, but the others were not.
    
    Change the remaining methods back to return a boolean.
    
    Change-Id: If4a9227f70bfcd85965e1febd45f4a75cc2505bd
    Signed-off-by: David Pursehouse <dpursehouse@collab.net>
    
  - Store replication tasks instead of ref-update events
    
    Fix the granularity of persistent events on disk by storing
    replication tasks rather than ref-update events.
    
    Ref-updates are triggering the replication tasks,
    however it is tricky to perform reference counting on the associated
    tasks reliably, due to all the different conditions of where a
    replication task can be in the replication queue.
    
    Fix a recurring issue on the persistence of ref-update events.
    The persisted ref-update events were either removed prematurely on the
    filesystem or left forever orphan even after the replication was completed
    on all remotes and target URLs.
    The problem was caused by the different granularity of the incoming
    ref-update events and the corresponding replication tasks queued
    and executed.
    
    Do not persist ref-update events anymore but include remote and
    target URLs at the replication tasks and persist those instead.
    
    The stored objects are replication tasks and not anymore ref-update
    events.
    
    Bug: Issue 11172
    Change-Id: I02d8cda0a124e8e3d2b9bb01b7d44f98ba717fcd
    
  - ReplicationIT: Don't swallow exceptions on failed repository operations
    
    The methods getRepo and getRef catch exceptions and return null, which
    will then cause NullPointerException on subsequent dereference, making
    it less easy to track down the actual cause.
    
    Remove the getRepo method and always open the repo in a try-with-resource
    that will throw the exception and fail the test if the repository could
    not be opened.
    
    Some calls to getRef are done in a consumer which means the method can't
    throw an exception. In these cases, it's OK for the method to return
    null because then the test will fail anyway due to InterruptedException
    being raised when the non-null was not returned within the timeout.
    
    Other callers of getRef however should not get the null value as it will
    cause NPE.
    
    Make getRef throw the exception, thus failing the test early, and add a
    variant method "checkedGetRef" which returns null and is used in the
    consumer.
    
    Also replace usage of printStackTrace with FluentLogger.
    
    Change-Id: I0f0caca03386c4fa5710f4c8e8fd4f798acead2b
    
  - ReplicationIT: Add explicit test for replication of new branch
    
    Change-Id: I67aa8b4aec05ad23b3c286d56a3b894eede7cd7e
    
  - ReplicationIT: Change test method name to reflect actual operation
    
    The test shouldReplicateNewBranch creates a new change and then
    verifies that the corresponding refs/changes/xx/yy/zzzzzz ref is
    replicated to the destination.
    
    Rename it to shouldReplicateNewChangeRef to match what it's actually
    doing.
    
    Change-Id: I32fe7237c8857907dd51d627a571f6ccb73741a3
    
  - Allow AdminApiFactory to be replaced dynamically
    
    Since change Ie760bf3e1 the GerritSshApi class is no longer a singleton,
    and is instead instantiated on demand by a new AdminApiFactory.
    
    This breaks implementations that consume the replication plugin as a
    library and extend the GerritSshApi, since the extended class no longer
    gets instantiated in place of GerritSshApi.
    
    Refactor it so that AdminApiFactory is an interface with a default
    implementation that gets bound as a dynamic item, which can be replaced
    by derived implementations.
    
    Change-Id: Ia150d6802e11015fa00ee9144b3dfbfa696c7a0d
    Signed-off-by: David Pursehouse <dpursehouse@collab.net>
    
1 file changed
tree: b2ae222be0a443c68e10ab1b7f10242a3d20fca6
  1. .settings/
  2. antlr3/
  3. contrib/
  4. Documentation/
  5. java/
  6. javatests/
  7. lib/
  8. plugins/
  9. polygerrit-ui/
  10. prolog/
  11. prologtests/
  12. proto/
  13. resources/
  14. tools/
  15. webapp/
  16. .bazelproject
  17. .bazelrc
  18. .bazelversion
  19. .editorconfig
  20. .git-blame-ignore-revs
  21. .gitignore
  22. .gitmodules
  23. .gitreview
  24. .mailmap
  25. .pydevproject
  26. BUILD
  27. COPYING
  28. INSTALL
  29. README.md
  30. SUBMITTING_PATCHES
  31. version.bzl
  32. WORKSPACE
README.md

Gerrit Code Review

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

Build Status

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 7 based Gerrit image:

    docker run -p 8080:8080 gerritforge/gerrit-centos7[:version]

To run a Ubuntu 15.04 based Gerrit image:

    docker run -p 8080:8080 gerritforge/gerrit-ubuntu15.04[:version]

NOTE: release is optional. Last released package of the version is installed if the release number is omitted.