Browse documentation

Integrations

GitLab integration setup

One GitLab connection covers both halves of the job: it tells Lineman which project and branch a piece of work happened on, and it writes each issue's running AI cost back onto that issue as a note. Self-managed instances are supported as well as gitlab.com.

Not generally available yet. GitLab sits behind the integrations feature flag, and connecting also needs Lineman to have registered a GitLab OAuth application. If that is not configured yet, the Connect button tells you so rather than sending you part-way into a sign-in that cannot finish.

Connect

  1. 1In your dashboard, open Integrations and choose GitLab.
  2. 2Enter your instance host. On GitLab SaaS that is gitlab.com; if you run your own instance it is your own domain, for example gitlab.acme.internal. There is no default, on purpose: guessing gitlab.com would send a self-managed customer's token to a server that is not theirs.
  3. 3Sign in to GitLab and approve access. Lineman then discovers the projects that identity can see, along with their default branches, so there is nothing to configure inside GitLab itself.
  4. 4Enable at least one project. Back on Lineman's GitLab page, the projects Lineman discovered are listed with every one switched off. Nothing is written to any issue until you switch one on, because Lineman edits your issues and that should be your decision rather than a side effect of connecting. Costs start appearing on the next scheduled run after that.

The host must be https. A plain http:// host is rejected when you connect, not quietly accepted. The access token behaves like a bearer credential, so anyone who can read the traffic can act as your connection, and failing the setup is the safer outcome. If your instance is only reachable over http, fix that first.

Two separate decisions per project

Once your projects are discovered you tick them for each half independently, because authorising a project for cost attribution is a different decision from letting Lineman write on its issues.

  • Authorise - treat spend on this project as expected. Spend Lineman sees on a project you have not ticked is flagged, so AI usage somewhere your team was not meant to be working stands out instead of blending in.
  • Track issues - allow the cost note on this project's issues. Leave it off and Lineman still attributes the spend in Cost Explorer, it just writes nothing into GitLab.

How work is matched to an issue

  • Use the #123 form. Lineman looks for a hash followed by a number in the branch name, for example feature/#412-retry-backoff. A bare number is deliberately not matched, because release/2024-01-15 would otherwise bill an entire release branch to issue 2024.
  • Issue numbers are per project, not global. A GitLab issue IID such as #123 only means something inside one project, so cost is always scoped to the project the branch belongs to. Two projects can each have a #123 and their totals never merge.
  • If your team already brands branches with bare numbers, set a custom matching pattern on the integration rather than renaming everyone's branches.

The cost note

For each tracked issue Lineman keeps one note showing the total AI cost across everyone who has worked on it. Each update edits that same note in place rather than adding another, and an unchanged total is skipped entirely, so nobody is notified about a number that did not move.

  • Amounts are shown in US dollars to two decimal places, for example $12.34. Lineman never reports cents.
  • The total is cumulative. It is every cost recorded against that issue so far, not the spend since the last update.

Do not edit the marker. The note begins with a hidden HTML comment that Lineman uses to recognise its own note. GitLab renders Markdown, so you will not see it on the issue, but if you edit the note and drop that line the next update cannot find the note and posts a second one. Editing the wording underneath is harmless, though it is overwritten on the next update.