GitLab CI

SuperCI runs GitLab CI jobs on the same providers, with the same order and limits, as GitHub Actions jobs. It works with GitLab.com and with a GitLab you host yourself.

Connect GitLab

Under Repositories, choose GitLab and follow the three steps:

1. Where it is: GitLab.com, or your own server’s address.
2. A token: create an access token with the scopes api, create_runner and manage_runner. The dialog links to the page with the name and scopes filled in. A project or group access token is enough, and safer than a personal one.
3. Paste it. The token is kept in your control plane’s secrets, nowhere else.

Then turn on the projects whose jobs should run on SuperCI. That adds a webhook to each.

Run a job

Give a job the tag:

test:
  tags: [superci]
  script:
    - npm test

Sizes work as in labels: tags: [superci-8cpu].

How it differs from GitHub

• Jobs run in Docker, as on GitLab’s own runners, with the image the job names. So they run on AWS and Cloudflare, not on Modal, and not on Windows.
• One runner per job. GitLab has no runner for exactly one job, so each job gets a project runner of its own, paused as soon as it takes a job and removed when the job ends.
• Forks: GitLab runs a fork’s merge-request pipelines in the fork’s project, so those never reach your runners.

Several GitLabs

Repositories → Another GitLab adds another server, or another account’s token on the same one. Each has its own projects and its own token, and their jobs share your providers and limits.

To replace a token (it expired, or you want a narrower one), open the connection’s settings and choose New token. The projects you turned on stay on.