| commit | 469efa8c0c75947f0d6157fa05f280477e294bac | [log] [tgz] |
|---|---|---|
| author | Fabio Ponciroli <ponch78@gmail.com> | Mon Jan 02 23:06:18 2023 +0100 |
| committer | Fabio Ponciroli <ponch78@gmail.com> | Mon Jan 02 23:21:02 2023 +0100 |
| tree | cfe1cad102a3e69dbda00e2aaea9fa4542554a19 | |
| parent | ff3272b223b48415d7742a3c3b6de17f52307f27 [diff] |
Document required installation of replication plugin lib The replication-status plugin relies on events defined in the replication plugin. Since Gerrit doesn't provide a way of defining dependencies among plugins, if replication-status loads before replication, some classes won't be available at startup. As a workaround the replication plugin can be added as a lib to make sure the needed classes are always available at startup. Bug: Issue 16554 Change-Id: I5a8b0faa6009759249ce6277633db1c75b08bcda
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 @PLUGIN@ depends on the replication plugin. Check the configuration section for more details.
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-url>/replication-status'
For instance, to assess the replication status of the project some/project to the https://github.com/some/project.git URL, the following endpoint should be called:
curl -v --user <user> '<gerrit-server>/a/projects/some%2Fproject/remotes/https%3A%2F%2Fgithub.com%2Fsome%2Fproject.git/replication-status'
A payload, similar to this may be returned:
{
"remotes": {
"https://github.com/some/project.git": {
"status": {
"refs/changes/01/1/meta": {
"type": "PUSH",
"status": "SUCCEEDED",
"when": 1626688830
},
"refs/changes/03/3/meta": {
"type": "PUSH",
"status": "SUCCEEDED",
"when": 1626688854
},
"refs/changes/03/3/1": {
"type": "PUSH",
"status": "SUCCEEDED",
"when": 1626688854
},
"refs/changes/02/2/1": {
"type": "PUSH",
"status": "SUCCEEDED",
"when": 1626688844
},
"refs/changes/02/2/meta": {
"type": "PUSH",
"status": "SUCCEEDED",
"when": 1626688844
},
"refs/changes/01/1/1": {
"type": "PUSH",
"status": "SUCCEEDED",
"when": 1626688830
},
"refs/changes/04/4/meta": {
"type": "PULL",
"status": "SUCCEEDED",
"when": 1628000641
},
"refs/changes/04/4/1": {
"type": "PULL",
"status": "SUCCEEDED",
"when": 1628000641
}
}
}
},
"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