commit | b2b7bbc71180774bf80eee676735dd3f9b747dc7 | [log] [tgz] |
---|---|---|
author | Marcin Czech <maczech@gmail.com> | Thu Aug 12 18:20:52 2021 +0200 |
committer | Marcin Czech <maczech@gmail.com> | Mon Aug 23 19:50:19 2021 +0200 |
tree | 55726d2cfe970d3a4af8f38e847033a460d413fd | |
parent | 1e3e011b190e5d9cd4e292fa744fd4dc4196dac2 [diff] |
Request by remote name instead of remote URL The replication-status currently accepts a remote-url as a URL segment. This can be tedious from a client point of view because the fully qualified replication-url might not be known plus user cannot ask for multiple urls which are logically grouped. To mitigate this situation use remote name instead of remote url. Bug: Issue 14803 Change-Id: Ibd6c2a943204cacc035b74fa34e34220417274c3
Record and display the repository's replication status without having to dig into the Gerrit replication_log
Consumes replication events and updates a cache with the latest replication status of specific refs to specific remotes.
The cache information is then exposed via a project's resource REST endpoint:
curl -v --user <user> '<gerrit-server>/a/projects/<project-name>/remotes/<remote-name>/replication-status'
For instance, to assess the replication status of the project some/project
to the https://github.com/some/project.git
URL with the replication configuration:
[remote "github-replication"] url = https://github.com/${name}.git
the following endpoint should be called:
curl -v --user <user> '<gerrit-server>/a/projects/some%2Fproject/remotes/github-replication/replication-status'
A payload, similar to this may be returned:
{ "remotes": { "https://github.com/some/project.git": { "status": { "refs/changes/01/1/meta": { "status": "SUCCEEDED", "when": 1626688830 }, "refs/changes/03/3/meta": { "status": "SUCCEEDED", "when": 1626688854 }, "refs/changes/03/3/1": { "status": "SUCCEEDED", "when": 1626688854 }, "refs/changes/02/2/1": { "status": "SUCCEEDED", "when": 1626688844 }, "refs/changes/02/2/meta": { "status": "SUCCEEDED", "when": 1626688844 }, "refs/changes/01/1/1": { "status": "SUCCEEDED", "when": 1626688830 } } } }, "status": "OK", "project": "some/project" }
The endpoint returns different HTTP response code depending on the result:
The REST-API response shows a status
field, which shows the overall replication-status of the projects for the specified remote.
OK
- all the refs have successfully replicatedFAILED
- Some refs have not replicated successfully