Unblu logo

Endpoints

The tool needs to be contacted from both SonarQube and GitLab.

Sonar endpoints

Sonar main endpoint

POST <server url>/u-sonar-status/sonar

This is the principal endpoint that receives a Webhook event sent by SonarQube.

Requests are processed asynchronously, meaning that SonarQube will receive a 202 Accepted response back immediately.

Example:

{
  "build_commit" : "6af21ad",
  "build_timestamp" : "2022-01-01T07:21:58.378413Z",
  "sonar_event_uuid" : "sonar-c9961b21-8554-4df8-8485-1aacd05b6ac4",
  "source" : "SONAR"
}

  • build_commit and build_timestamp allow you to identify the u-sonar-status version.

  • sonar_event_uuid is a value used to identify the request.

Sonar blocking endpoint

A secondary endpoint where the process in done in a blocking way is available as well:

POST <server url>/u-sonar-status/sonar-blocking

With this blocking endpoint you get more information about the created comment in the returned response.

Example:

{
  "build_commit" : "6af21ad",
  "build_timestamp" : "2022-01-01T07:21:58.378413Z",
  "sonar_event_uuid" : "sonar-c9961b21-8554-4df8-8485-1aacd05b6ac4",
  "sonar_task_id" : "AYbMZT8ngxz2HxwOGdhr",
  "source" : "SONAR",
  "gitlab_project_id" : 56,
  "gitlab_merge_request_iid" : 19,
  "gitlab_external_status_check_id" : 3,
  "gitlab_external_status_check_status_id" : 4
}

Using this endpoint might be interesting for debugging purposes, since you see the response containing the details of the action.

Sonar replay endpoint

An additional endpoint is available to trigger the process using some simplified input compared to the event sent by the Sonar Webhook mechanism.

POST <server url>/u-sonar-status/sonar-replay

Body:

{
  "sonar_event_uuid" : "sonar-c9961b21-8554-4df8-8485-1aacd05b6ac4",
  "task_id" : "AYbMZT8ngxz2HxwOGdhr",
  "revision" : "ba22a8ce46acee878adec5ffee5a5621c9d35ac1",
  "project_key" : "project_56",
  "branch_name" : "100",
  "branch_type" : "PULL_REQUEST",
  "quality_gate_status" : "OK"
}

The response is the same as in the blocking case.

Using this endpoint is interesting to trigger again the u-sonar-status action for a given event using curl, without having to send the complete webhook event body.

GitLab endpoints

GitLab main endpoint

POST <server url>/u-gitlab-status/gitlab

This is to receive the external check payload (see Example payload sent to external service) sent by GitLab.

Requests are processed asynchronously, meaning that GitLab will receive a 202 Accepted response back immediately.

Example:

{
  "build_commit" : "6af21ad",
  "build_timestamp" : "2022-01-01T07:21:58.378413Z",
  "gitlab_event_uuid" : "gitlab-c289ee78-ab41-4656-ad7a-3d8ea464fb25",
  "source" : "GITLAB"
}

  • build_commit and build_timestamp allow you to identify the u-gitlab-status version.

  • gitlab_event_uuid is a value used to identify the request.

GitLab blocking endpoint

A secondary endpoint where the process in done in a blocking way is available as well:

POST <server url>/u-gitlab-status/gitlab-blocking

With this blocking endpoint you get more information about the created comment in the returned response.

Example:

{
  "build_commit" : "6af21ad",
  "build_timestamp" : "2022-01-01T07:21:58.378413Z",
  "gitlab_event_uuid" : "gitlab-c289ee78-ab41-4656-ad7a-3d8ea464fb25",
  "source" : "GITLAB",
  "gitlab_project_id" : 56,
  "gitlab_merge_request_iid" : 19,
  "gitlab_external_status_check_id" : 3,
  "gitlab_external_status_check_status_id" : 4
}

Using this endpoint might be interesting for debugging purposes, since you see the response containing the details of the action.

GitLab replay endpoint

An additional endpoint is available to trigger the process using some simplified input compared to the event sent by the GitLab Webhook mechanism.

POST <server url>/u-gitlab-status/gitlab-replay

Body:

{
  "project_id" : 56,
  "merge_request_iid" : 100,
  "merge_request_source_branch" : "patch-2",
  "merge_request_last_commit_sha" : "ba22a8ce46acee878adec5ffee5a5621c9d35ac1",
  "external_status_check_id" : 3,
  "external_status_check_name" : "SONAR",
  "external_status_check_url" : "https://company.example.com/u-sonar-status/gitlab",
  "gitlab_event_uuid" : "gitlab-c289ee78-ab41-4656-ad7a-3d8ea464fb25"
}

The response is the same as in the blocking case.

Using this endpoint is interesting to trigger again the u-gitlab-status action for a given event using curl, without having to send the complete webhook event body.

Readiness and liveness probes

The application provides standard probes:

  • <server url>/q/health/live: The application is up and running (liveness).

  • <server url>/q/health/ready: The application is ready to serve requests (readiness).

  • <server url>/q/health: Accumulating all health check procedures in the application.

Info endpoint

The application provides some information about the current version:

  • <server url>/q/info

This can be turned off with the quarkus configuration property quarkus.info.enabled set to false.