Skip to content
Fluid Attacks Development Portal

GitLab bot

This is an AWS Lambda handler for GitLab Webhooks built with TypeScript, which enables performing actions in response to GitLab events.

Getting Started

To start developing actions, run:

Terminal window
cd common/ci/infra/module/gitlab-bot
npm install

You can find the Webhook configuration here.

You can find the production logs here or use this link for easy filtering.

Actions

Merge request merge

Once an MR is approved, this bot takes care of rebasing and merging so you don’t have to.

Merge request review

This bot leverages the power of Danger JS to provide automated reviews within Merge requests.

Danger JS provides a variety of APIs that can be used to build and extend checks performed by the bot.

To test any changes in the danger file, use the following command:

Terminal window
npx danger pr --dangerfile ./src/mr-review/dangerfile.ts MERGE_REQUEST_URL
  • Replace MERGE_REQUEST_URL with the actual URL of the merge request you want to test.
  • This command runs Danger Js against the specified merge request using the rules defined in mr-review/dangerfile.ts.

Pipeline cancel

This bot cancels unnecessary pipelines when pushing changes to the same branch.

It also cancels pipelines when rebasing an open Merge Request, as per team policy, only the first MR pipeline must succeed, so these secondary pipelines aren’t required and canceling them can lead to savings in compute resources.

Development considerations

Concurrency

This bot will be triggered concurrently by GitLab, with several executions happening at the same time.

Keep that in mind when calling GitLab’s API, as some operations rely on state pre-conditions, for instance, you can’t approve the same MR twice.

It is advisable to embrace the fact they are going to race, and just handle the cases where GitLab may complain about certain actions being performed more than once.

Execution time

GitLab has a timeout for webhooks, meaning that executions lasting over 10 seconds will be considered as failed.

GitLab then retries the calls with backoff, and if the failures persist, it automatically disables the webhook.

Make the most out of concurrent promises, rather than sequential actions where possible.

Infinite loops

Calling GitLab APIs that result in another webhook call may be risky, as it can cause frequent unintended invocations that can impact the cost and performance attributes of the bot.

Ensure the function always has an exit condition that would break these loops.