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
2 files changed
tree: cfe1cad102a3e69dbda00e2aaea9fa4542554a19
  1. proto/
  2. src/
  3. .gitignore
  4. BUILD
  5. Jenkinsfile
  6. LICENSE
  7. README.md
README.md

Replication-status

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.

Dependencies

The @PLUGIN@ depends on the replication plugin. Check the configuration section for more details.

REST API

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'
  • : an (url-encoded) project repository
  • : an (url-encoded) remote URL for the replication

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"
}

HTTP status

The endpoint returns different HTTP response code depending on the result:

  • 200 OK - The endpoint was called successfully, and a payload returned
  • 404 Not Found - Project was not found
  • 500 Failure - An unexpected server error occurred
  • 403 Forbidden - The user has no permission to query the endpoint. Only Administrators and project owners are allowed

Overall status

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 replicated
  • FAILED - Some refs have not replicated successfully

TODO

  • Does not consume pull-replication events.