carbon-gate

Inspiration

Every merge request starts a pipeline, and every pipeline uses energy. Code review looks at the diff, but almost nobody reviews what the pipeline itself costs. We wanted that cost to be visible in the merge request and kept within a budget, the same way tests are.

What it does

• Each CI job records its own start and end time as a tiny artifact (.gitlab/record-timing.sh).
• A final carbon_gate job gathers those artifacts through needs, turns runner-minutes into a Software Carbon Intensity (SCI) estimate per pipeline run, and compares it with the latest successful main report, downloaded with the job token only. No personal access token and no project CI/CD variables are needed, so it works with a Developer role.
• If the merge request pipeline is more than 20% above main, the job fails and the report lists the waste it found in .gitlab-ci.yml (no cache, oversized runner, runs on every change, no timeout).
• A human decides what happens next by mentioning the Carbon fixer flow in an MR comment. The GitLab Duo Agent Platform flow (analyst → fixer → reporter) reads the failed job log, the CI file and the diff, opens a separate fix MR against the source branch, and posts a summary. It never removes tests, security scans or the gate itself.
• Every main pipeline appends a point to a GitLab Pages dashboard, so the team can watch pipeline carbon over time.

Real run in this project (Oct 21, 2026)

• main baseline: 0.15 gCO2eq per pipeline run (pipeline #2970155069, 1.4 runner-minutes).
• Regression MR !2 (unit tests moved to a medium runner + heavy packages installed on every run): 0.19 g, +23.7% vs budget +20% → carbon_gate failed (pipeline #2970161875).
• A human mentioned @ai-carbon-fixer-gitlab-ai-hackathon on !2 → Duo session 9791428 → fix MR !3 (back to the small runner, unused packages removed, pip cache added).
• Fix pipeline #2970169563: 0.16 g, +4.3% → within budget. !3 and !2 were merged; the next main pipeline (#2970175486, 0.17 g) was appended to the Pages dashboard.

How we built it

Python + PyYAML CLI (measure, gate, scan, fix, dashboard), GitLab CI artifacts and needs, the job-artifact download API with CI_JOB_TOKEN, a GitLab Duo Agent Platform custom flow (flow registry v1, three agent components, Mention trigger), and GitLab Pages. The code, tests and docs were written by AI coding agents (Claude- and GPT-family). The entrant, WooYoung Choi, chose the direction and the project name and approved each public step.

SCI method

SCI = ((E × I) + M) / R with R = one instrumented pipeline run. Energy comes from job duration × runner vCPU/memory power (Cloud Carbon Footprint coefficients, PUE 1.1); grid intensity from Google Cloud region data; embodied emissions and 50% CPU utilisation are explicit assumptions. Gate/Pages jobs and artifact upload overhead are excluded. These are estimates, not metered measurements.

Challenges we ran into

The hackathon project gives a Developer role, which cannot set CI/CD variables. We redesigned the gate to need no personal token: timings travel as artifacts and the baseline comes from the job-artifact endpoint the job token can already read. CI also cannot comment on MRs, so the flow is triggered by a human mention, which matches the supervised design we wanted.

Accomplishments that we're proud of

The full loop ran on real GitLab: a regression was blocked, a Duo flow proposed a reasonable fix from the job log alone, and the fixed pipeline passed inside the budget.

What we learned

Most pipeline waste is configuration, not code: caches, runner size and when a job runs. A budget relative to main is easier to agree on than an absolute limit.

What's next

Measured runner telemetry instead of duration estimates, per-job budgets, and scheduled pipelines for heavy suites.tlab-ci gitlab-duo-agent-platform gitlab-pages green-software-foundation-sci

Built With

• gitlab
• gitlab-ci
• gitlab-duo-agent-platform
• gitlab-pages
• green-software-foundation-sci
• python
• pyyaml