GitLab (Cloud)
Connect a GitLab.com group or your personal namespace: every project you maintain in it is proven, private ones included, and can be scanned.
The GitLab (Cloud) integration connects a GitLab.com group (subgroups included) or your personal namespace to your mlab.sh organization. Every project in it that you maintain is added to your infrastructure already proven, private projects included, with no .mlab file to commit.
On your own GitLab instance? See GitLab (Self-Managed).
mlab.sh only reads: nothing is installed in your projects and nothing is written to them. It asks GitLab for two read-only scopes:
| Scope | Why |
|---|---|
read_api | List your groups and projects, read their settings for the repository pages |
read_repository | Clone the code to scan it |
Connect
Open the catalog
In Organization → Infrastructure → Integrations, click Add an integration, then GitLab (Cloud). Owners and admins can connect integrations.
Authorize mlab.sh on GitLab
GitLab shows the two scopes above. Click Authorize.
Pick what to connect
mlab.sh lists your personal namespace and every group where you are Maintainer or Owner. Pick one and click Connect. To connect another group, use Add another on the GitLab card and pick it: GitLab does not ask again.
Which projects are proven
A project is proven when the person who connected the namespace is Maintainer or Owner on it: GitLab only lets those roles change a project. Projects where that person is Developer or below are not added. Archived projects are left out.
The rule keeps being checked: if that person loses the role, or leaves the group, the projects lose their proof at the next sync. Someone else can then reconnect the namespace with their own account.
One namespace belongs to one mlab.sh organization.
Keeping up with GitLab
GitLab sends mlab.sh no webhook (the integration only reads), so mlab.sh keeps up on its own:
- Every day, each connected namespace is read again: new projects appear, removed ones lose their proof, renamed and moved ones are followed by their GitLab id.
- Every few minutes, the head of each project's default branch is compared with the last one seen. A new commit counts as a push: it starts the scans set to run on push and refreshes the repository pages.
- Resync on the GitLab card reads the namespace right away.
Manage connected namespaces
Each namespace has a card on the Integrations page with its projects, who connected it, when it was last synced, and Open on GitLab, Resync and Disconnect.
- Disconnect revokes mlab.sh's access on GitLab. Tick Also remove its repositories to take them out of your infrastructure: projects that were already scanned are always kept, without their proof, so their scan history stays. Unticked, every project stays listed as Access removed.
- Access lost: when GitLab refuses mlab.sh's access (the authorization was revoked on GitLab, or the person who connected it lost their role or their account), the card says so and offers Reconnect. Reconnecting the same namespace keeps its projects and their history.
- Unreachable for a week: if a namespace cannot be read for seven days in a row, its projects that were never scanned are removed from your infrastructure; scanned ones are kept. A shorter outage changes nothing.
You can revoke mlab.sh at any time on GitLab too, in Preferences → Applications → Authorized applications.
Repository pages
GitLab projects get the same tabs as GitHub repositories in RedKit → Code:
- Overview: description, topics, visibility, default branch, license, size, creation and last activity, stars and forks, open issues, languages.
- Activity: commits per week over the last year, the latest commits with their signature status, top contributors, latest releases.
- Hygiene: whether the default branch is protected, nobody can push to it directly and an approval is required, force pushes are blocked, pipelines must pass before a merge, commits are signed, GitLab secret detection runs in CI, and whether the project has a security policy, code owners, Renovate, a license, and no committed credential file. It also lists who has Maintainer rights or more.
What is read from GitLab is kept until the project changes, so the tabs open instantly; the date it was read is shown at the bottom of each tab.
Troubleshooting
| Message | What to do |
|---|---|
| This connection could not be confirmed as yours | Start again from the catalog: the GitLab round trip must start and end in the same browser session. |
| You do not maintain this GitLab namespace | Ask an Owner or Maintainer of the group to connect it, or connect a group where you have that role. |
| Connected to another organization | One namespace belongs to one mlab.sh organization. If it is yours, contact us. |
| GitLab could not be reached | GitLab.com was unavailable for a moment. Try again; nothing was connected. |
Data and privacy
mlab.sh reads your repositories on your instruction, in read-only mode, as a processor for your organization. GitLab is your provider, not a sub-processor of mlab.sh. What is read, what is kept and for how long is described in the privacy policy, the data processing agreement and the terms of service.
GitLab is a trademark of GitLab Inc. mlab.sh is not affiliated with, sponsored or endorsed by GitLab Inc.