Green Pipeline Steward

• 

• 

• 

• 

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Green Pipeline Steward

Inspiration

Two costs keep growing after the code is written. The first is people: reviewing, testing, scanning, releasing and babysitting pipelines. The second nobody sees: every push starts runners, and many pipelines do the same work twice, pull a 400 MB image to run a 10-second lint, or keep running after a newer commit has replaced them. We wanted agents that take the first cost off the team and measure and cut the second, without charging more carbon than they save.

What it does

Hands-off, issue to production. Label an issue steward::autopilot and walk away. The autopilot flow's supervisor runs six Duo sub-agents. A planner posts a plan on the issue. A developer branches, implements, runs the tests locally and opens the MR. A test writer fills test gaps. A reviewer checks security (input bounds, injection, secrets, CSP), accessibility (labels, focus, announcements, contrast) and carbon. A carbon check runs the repository's audit tool. A scribe writes the changelog. If the review approves, the MR gets the autopilot label. The pipeline then merges it when every job passes, packages it, publishes the Carbon Ledger dashboard to GitLab Pages and posts the result and the pipeline's grams of CO2e on the original issue. The same pipeline carries keyless Cloud Run jobs (staging with no traffic, verify, promote that exact revision, verify again); they switch on with three Google Cloud variables and are not configured in the published project.

Hands-off, keeping pipelines healthy and lean. The pipeline flow is triggered by pipeline events. A failed MR pipeline gets a diagnosis and a fix commit on its branch. A failed default-branch or monitoring pipeline gets an incident issue with a rollback command. A passed weekly audit starts the carbon steward. It reads the deterministic audit of .gitlab-ci.yml against real job durations and opens an optimisation MR only when the projected saving is at least 3x the estimated footprint of the agent run itself.

Supervised and assisted modes. The review flow reviews human MRs, commits missing tests and submits a verdict. The release flow drafts notes, waits for approval in the session before it writes anything. The Carbon Advisor custom agent answers cost questions in Duo Chat with numbers from our MCP server.

Governance. One gate checks the MIT licence, the AGENTS.md guardrails, all four flows (with our offline flow linter), a per-pipeline carbon budget, and that no agent-labelled MR touches protected files. It also scans for secrets.

How we built it

• Duo Agent Platform: four custom flows in flow-registry v1 YAML: a supervisor with six sub-agents, an approval HumanInputComponent, and a OneOffComponent verdict. They are triggered by work item, merge request, pipeline and mention events. Also a custom agent, an MCP server (stdio, no SDK), AGENTS.md read into flows, a project skill, Code Review instructions and agent-config.yml for flow execution.
• Design rule: agents decide, code counts. Every gram comes from greensteward/sci.py, which is tested. The agents read JSON and never do arithmetic. Two platform facts shaped the design: flows cannot trigger flows, and agents cannot merge. So the hands-off chain is one supervisor flow plus deterministic CI jobs for merge, promotion and notification.
• CI/CD: lint, flow lint, tests with coverage, live smoke test, three security scanners, a package registry upload, Cloud Run staging and production with keyless OIDC deploys (ready, needs a GCP project), GitLab release, Pages dashboard, scheduled monitoring and audits, the carbon meter on every job, and the governance gate.
• App: Carbon Ledger, a standard-library Python API and a static dashboard with no inline script under a strict CSP.

Sustainability (quantified)

Method: Green Software Foundation SCI = ((E x I) + M) per R, with Cloud Carbon Footprint coefficients for Google Cloud and Google's 2025 grid intensity per region. R is one pipeline (report) or one push (audit). The full method, boundary and assumptions are in docs/SUSTAINABILITY.md.

• The audit takes a typical wasteful pipeline from 3.59 to 0.27 gCO2e per push (-92 %) and from 542 to 95 runner-seconds. At 300 pushes a month: ~1 kg CO2e and ~2,240 runner-minutes saved per month for one small project.
• We count the agents' own footprint with a pessimistic proxy (34.9 g per carbon-steward run). The payback gate means an optimisation MR exists only if it saves at least 3x that.
• Measured: python:3.12 vs -slim is 412 vs 43 MB per job pull; cloud-sdk latest vs alpine is 1,157 vs 127 MB. A warm cache cuts dependency install by 38 %. Our app container is 43 MB, idles at 18 MiB and is healthy in 0.9 s.
• Deployment target when Google Cloud is configured: Cloud Run in europe-west9 at 15.8 gCO2e/kWh against 579 in us-east1, scaled to zero. (The published project deploys the dashboard to GitLab Pages only.)
• Agent efficiency: API-only flows skip the clone. A no-tool triage gate ends most pipeline events after one small call. The supervisor has a delegation budget. Flows cannot retrigger themselves.

Measured on GitLab (2026-10-15, real pipelines):

• Two hands-off runs, issue to merged MR with no human action: 9 min 55 s and 15 min. The issue note reports the default-branch pipeline at 0.303 gCO2e (3.3 runner-minutes).
• The carbon steward's first MR, measured after a human merged it: the five Python jobs both pipelines ran went from 171.2 to 117.4 runner-seconds (-31 %), and the whole default-branch pipeline from 0.395 to 0.310 gCO2e (-22 %) while running one more job. The audit had projected 4.73 -> 1.10 g per push for all findings (payback 31x); the MR applied only the MEDIUM one, as designed.
• The whole day's agent work (32 flow sessions) cost 69.6 GitLab Credits.

Challenges we ran into

• Flows cannot be triggered by bots or other flows, and agents cannot merge. We moved the "end of the chain" into CI jobs instead of pretending otherwise.
• Keeping agents from guessing numbers. The fix was to move all arithmetic into tested code and make the agents quote it.
• Avoiding a false "0 g". Every tool that can find nothing reports ABSENT and refuses to print zero.
• The AI Catalog validator rejects some fields the flow runtime spec documents (max_cycles, require_tool_approval) and did not know one tool name. Our offline flow linter now checks exactly that.
• Labels race pipelines: the reviewer labels the MR seconds after the last commit's pipeline starts. The merge decision now reads the MR's labels when the pipeline ends, not when it starts.
• A protected API token is, rightly, invisible to MR pipelines on agent branches and to the agents themselves. The MR pipeline's last job starts a short default-branch pipeline (with its own job token) that holds the token, re-checks the label and the pipeline, posts the carbon note and merges.
• Our own agents found three real bugs in our pipeline on day one: a docs-only push that could not create a pipeline, a monitor probing API routes on static Pages, and an issue note posted before the carbon report existed. All three are fixed, and the first two incidents were closed by the fixing commits.

Accomplishments we're proud of

• A full hands-off loop across all nine DevSecOps stages, with autonomy you can dial with one variable.
• An optimisation agent that has to pay back its own emissions before it acts.
• 166 tests, an offline validator for Duo flow YAML that also knows what the AI Catalog rejects, and a pipeline that passes its own carbon audit.

What we learned

Agentic automation needs the same discipline as any production system: guardrails as code, a governance gate agents cannot talk their way past, a budget on delegations, and a cost model for the agents themselves.

What's next

Hour-by-hour carbon-aware scheduling of non-urgent jobs from live grid data, per-runner energy telemetry instead of coefficients, and publishing the flows and the Carbon Advisor to the AI Catalog for other projects.

Testing instructions for judges

1. Open the repository: README has the architecture diagram, the trigger table and the stage table.
2. Pipelines: Build > Pipelines shows the full history. Open any carbon:report job for carbon/report.md and carbon/audit.md.
3. Live: the Carbon Ledger dashboard on GitLab Pages, https://showcase-79bbfe.gitlab.io (Operate > Environments > dashboard).
4. Locally: pip install -r requirements-dev.txt && python -m pytest -q, then python -m greensteward.ci_audit examples/wasteful.gitlab-ci.yml.
5. The flows are in .gitlab/duo/flows/. The steps to enable them in any project are in PUBLISH_CHECKLIST.md, section 4.

Built With

• gitlab
• gitlab-ci
• gitlab-duo
• gitlab-pages
• hyperframes
• mcp
• python
• sci