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:

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

Issue review

Whenever an issue is opened or updated, the bot will scan it’s content, and perform actions to help keep things safe and organized, like marking issues with attachments as confidential.

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:

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.

Trunk pipeline failures

This bot automatically creates a new issue on the universe project whenever it detects a failed pipeline on trunk.

It filters jobs failed due to initialization problems or deployment failures due to state locks (Since there is a scheduler in charge of cleaning those)

Development considerations

Access Token

This bot relies on UNIVERSE_API_TOKEN, a project access token, to interact with GitLab’s API.

The token will be rotated regularly, and when it happens, you will see a different account name used by the bot.

Note

The name is chosen creatively by the engineer in charge of performing the secret rotation.

After the secret is rotated, a maintainer will need to update the Merge Request approval rule, following these steps, and if there are any open Merge Requests at that moment, each of them will need to be updated by clicking edit, expanding the approval rules section, clicking Reset to project defaults, and saving changes.

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.