| commit | c476d76ed540b2f8541ca9d6da15c8d09925fa59 | [log] [tgz] |
|---|---|---|
| author | Saša Živkov <sasa.zivkov@sap.com> | Thu Aug 01 15:07:29 2019 +0200 |
| committer | Gerrit Code Review <noreply-gerritcodereview@google.com> | Thu Aug 01 13:07:29 2019 +0000 |
| tree | 89f6197c55741e346cbf663bba37897dc34cb008 | |
| parent | 5bd270fafe971e1b532538e27bc494f03645b3ef [diff] |
Update git submodules
* Update plugins/replication from branch 'stable-2.16'
to d33615ca4eae3f73b8b90e46edefc1584ebf458d
- Create missing repository only at the remote we are pushing to
When replication of a ref failed due to missing remote repository at one
remote site, we then initiated creation of the missing repository on all
remotes where this repository is replicated. The creation of the missing
repository is considered to be success if it succeeded for all remotes
and only in this case the ref replication was rescheduled. This logic
could cause a ref replication to not be rescheduled when creation of a
missing repository fails in a remote which is unrelated to the current
push operation. For example, if we replicate to two remote sites:
[remote "foo"]
url = https://foo.org/...
adminUrl = ssh://gerrit@foo.org/...
[remote "bar"]
url = https://bar.org/...
adminUrl = ssh://gerrit@bar.org/...
and if during a push to "foo" we find that the repository is missing
then we will try to create it on both "foo" and "bar". It could happen
that the creation of the missing repository succeeds on "foo" and then
fails on "bar" because "bar" is unreachable or down at that moment.
In this case the replication to "foo" will not be rescheduled but it
should be as we successfully created the missing repository in "foo".
Create missing repository only under the (admin) URL in the same remote.
Note that there will be one ref replication task for each remote which
ensures that the missing repository will be created in all remotes.
Change-Id: Idbc3f614df53bb3aabcc4cf6cb0d6540e7000e29
(cherry picked from commit abafb83c47eb50c0ec5ce9a4b8d04dc355d5a5bf)
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 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.