GitLab integration

The GitLab integration records what your team ships, so a change in your numbers sits next to the release that might have caused it. You sign in once, pick your projects, and CoNote does the rest. There are no links or keys to copy anywhere.

What lands on your timeline

Event	What you see	On by default
Deployment	"Deployed shop to production (main → 3a7f2c1a)"	Yes
Release	"Released shop v2.1.0" with the release notes	Yes
Merged merge request	"Merged: New checkout flow (!412)"	No
Push	"Pushed to shop (main → 3a7f2c1a)"	No
Failed deployment or pipeline	An Incident note	No

A deployment is the moment something actually went live, which is usually what you want to line up against your metrics. A merge is the moment code was accepted, which can be hours or days earlier. That is why deployments are on by default and pushes are not.

Every note links back to GitLab, and each event is recorded once even if it is seen twice.

Setting it up

Name it and connect
In Integrations, choose GitLab. Give it a name and press Connect GitLab. That is everything CoNote asks before the connection exists.
Sign in to GitLab
GitLab asks once whether CoNote may read your projects. CoNote only ever reads: it can never write to your code, and it cannot see anything your own account cannot see.
Choose what to log
You land back in CoNote, and now every setting is filled from your own account: your projects and the environments they deploy to. Pick what you want, choose how much history to import, and save.

CoNote checks GitLab every 15 minutes rather than being notified the second something happens. That is deliberate: setting up the notification for you would require write access to your projects, which a tool that never writes should not be asking for. If you want changes within seconds, you can set that notification up yourself, see Instant updates below.

Instant updates (optional)

Nothing below is required. Your timeline already fills itself; this only shortens the wait from a few minutes to a few seconds, and it is worth doing if you line deploys up against a metric that moves by the minute.

Copy the link and the token from CoNote
Open the GitLab integration's settings. Copy the Instant updates link. Under it, press Regenerate on the Instant updates token to reveal a token, and copy that too. The token is shown once, so copy it before you leave the page.
Add them to your GitLab project
In GitLab, open the project and go to Settings → Webhooks (the section where tools send updates from) → Add new webhook. Paste the link into URL and the token into Secret token, which is how GitLab proves to CoNote that the message really came from you.
Tick the events you log
Under Trigger, tick Deployment events and Releases events. Add Merge request events, Pipeline events or Push events if you have those switched on in CoNote. Then press Add webhook.

Repeat that per project you want instant, and skip the ones you don't. CoNote keeps checking every 15 minutes underneath either way, so a webhook that stops working never costs you an entry, and an event that arrives twice is still only recorded once.

Importing your history

When you connect, CoNote reads your past deployments, releases and merged merge requests, going back as far as you choose: 30 days, three months, a year or three years. Unlike GitHub, pushes are included, because GitLab keeps full repository history.

Large imports can push you past your plan's note limit. The extra notes are still collected, but stay locked until you upgrade. A big account is imported a few projects at a time, so the first notes appear within minutes and the rest follow over the next hour or so.

Narrowing what gets logged

Projects. Pick from the ones your account can see. Selecting none logs all of them.

Environments. CoNote reads the environments your projects actually deploy to and offers them as a list, so there is nothing to type. Selecting none logs all of them, review environments included. If your setup creates a review environment per merge request, select just production.

Branches. Empty means the project's default branch. You can also name patterns, for example main, release/*.

Paths. Only relevant when pushes are switched on. Name the folders you care about, for example apps/web/**, and a push that touches nothing else stays off the timeline. Empty logs every push.

Seats and billing

GitLab counts as one seat, no matter how many projects you log. Setting it up is free: the seat is only charged once the connection has proven it works. Until you finish signing in, the integration reads Not connected and costs nothing.

Self-hosted GitLab

This integration connects to gitlab.com. A self-hosted instance cannot use it, because the sign-in has to be registered on that instance itself. If you run your own GitLab, tell us and we will look at what it takes.

When something stops working

If the authorization is revoked, the integration switches to Needs attention and tells you what happened. Signing in again restores it, and nothing already on your timeline is lost.