Unblu logo

Endpoints

Main endpoint

POST <server url>/u-needs-work/event

This is the principal endpoint, that receive the Comment Webhook event 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" : "62940263-b495-4f7e-b0e8-578c7307f13d"
}

  • build_commit and build_timestamp allow you to identify the u-needs-work version.

  • gitlab_event_uuid is the value received in the X-Gitlab-Event-UUID header.

Blocking endpoint

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

POST <server url>/u-needs-work/event-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" : "62940263-b495-4f7e-b0e8-578c7307f13d",
  "needs_work_note" : {
    "project_id" : 56,
    "note_id" : 42395,
    "note_author_id" : 139,
    "note_content" : "[John Smith](https://gitlab.example.com/jsmith) [requested](https://gitlab.example.com/a_project/-/merge_requests/34#note_1234) changes on this MR.\n\n:eye_in_speech_bubble: [New changes](https://gitlab.example.com/a_project/-/merge_requests/34/diffs?start_sha=e54b4d028af6509e3b97467b153e16753c35747d) since the comment.",
    "mr_iid" : 34,
    "mr_last_commit_sha" : "e54b4d028af6509e3b97467b153e16753c35747d",
    "mr_web_url" : "https://gitlab.example.com/a_project/-/merge_requests/34"
  },
  "needs_work_note_type" : "ADDED"
}

Since GitLab keeps the response obtained when delivering a webhook event and displays it in the webhook admin page, using this endpoint might be interesting for debugging purpose.

Replay endpoint

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

POST <server url>/u-needs-work/replay

Body:

{
  "project_id" : 56,
  "note_id" : 42333,
  "note_web_url" : "https://gitlab.example.com/a_project/-/merge_requests/34#note_42333",
  "note_author_id" : 37,
  "note_content" : "This needs work!",
  "mr_iid" : 34,
  "mr_last_commit_sha" : "e54b4d028af6509e3b97467b153e16753c35747d",
  "mr_web_url" : "https://gitlab.example.com/a_project/-/merge_requests/34",
  "user_name" : "John Smith",
  "gitlab_event_uuid" : "test-8902345"
}

The response is the same as in the blocking case.

Using this endpoint is interesting to trigger again the u-needs-work 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.