Green CI Auto-Optimizer

AI flow for GitLab that skips wasted CI runs and safely proposes pipeline fixes.

Comment

Inspiration

AI writing code is no longer the bottleneck. In most teams, the real slowdown happens around everything around the code: slow CI pipelines, duplicate runs, unnecessary rebuilds, stale jobs chewing through runner minutes, and developers waiting for feedback that should have been fast.

That is the problem that inspired Green CI Auto-Optimizer.

We wanted to build something that felt like a real GitLab teammate, not a chatbot. Instead of answering questions about CI, it reacts to a merge request, inspects the repository and pipeline context, identifies waste, and then takes action safely. We were especially motivated by a simple but painful example: a docs-only merge request triggering a full monorepo pipeline. That is wasted compute, wasted time, and wasted developer focus.

This project was also inspired by the sustainability angle in software delivery. Many teams want “greener” engineering practices, but they do not have a practical way to spot unnecessary CI spend or convert that insight into safe changes. We wanted to make that measurable, visible, and actionable inside GitLab.

What it does

Green CI Auto-Optimizer is an autonomous GitLab Duo flow that analyzes merge requests for CI waste and then responds in one of two safe ways:

  • If the repository matches the expected contract and the change is high-confidence, it creates a CI-only optimization merge request
  • If patching is not safe enough, it falls back to a comment-only report with clear recommendations

The flow is designed for GitLab repositories that use a root .gitlab-ci.yml, especially Node/TypeScript monorepo-style projects like our demo repo.

It looks for waste patterns such as:

  • duplicate push + merge request pipelines
  • docs-only changes triggering full pipelines
  • missing rules:changes
  • no dependency cache or poor cache reuse
  • jobs that should be interruptible
  • excessive artifact retention and broad artifact paths
  • redundant job structure and unnecessary rebuilds

It then scores the pipeline using a transparent Green CI Score and explains the reasoning in plain English. The scoring rubric includes:

  • duplicate pipeline suppression
  • path-aware execution and docs-only fast paths
  • cache quality and lockfile reuse
  • interruptibility and stale-run cancellation friendliness
  • artifact hygiene
  • runtime hygiene and job/stage scope

To strengthen the impact story, the project also includes a Google Cloud BigQuery-backed evidence layer. GitLab Duo handles the reasoning and workflow automation, while Google Cloud stores before/after pipeline metrics and supports auditable impact reporting. That lets us show not only what the agent changed, but also why it mattered.

In the demo flow, the agent reacts to a real merge request, analyzes pipeline waste, and produces an optimization outcome based on GitLab-native context and tools. The result is a safer, faster, lower-waste CI workflow.

How we built it

We built the project as a public custom GitLab Duo flow on the GitLab Duo Agent Platform.

The flow is split into three purpose-built agents:

  1. Waste Profiler

    • reads merge request context
    • inspects .gitlab-ci.yml
    • checks diffs, repository structure, pipeline evidence, and job signals
    • computes the baseline Green CI Score
    • produces a ranked waste report

  2. CI Optimizer

    • consumes the profiler’s output
    • applies only allowed CI changes
    • validates the generated config with ci_linter
    • creates a clean optimization branch and merge request when safe

  3. Impact Reporter

    • posts the human-readable result back to the original merge request
    • summarizes findings, expected impact, rollback safety, and measured vs estimated outcomes

We intentionally kept the automation conservative. The flow is allowed to edit CI files only. It does not touch product code. That guardrail is important for both trust and usability.

GitLab Duo tools used

The flow uses GitLab Duo tools such as:

  • build_review_merge_request_context
  • get_merge_request
  • list_merge_request_diffs
  • get_pipeline_errors
  • get_pipeline_failing_jobs
  • get_job_logs
  • get_repository_file
  • list_repository_tree
  • gitlab_blob_search
  • gitlab_api_get
  • ci_linter
  • create_commit
  • create_merge_request
  • create_merge_request_note

That matters because this project is not simulating GitLab usage from the outside. It is built to run inside the GitLab Duo Agent Platform and use GitLab’s trigger, context, and action model the way the challenge intended.

Anthropic + Google Cloud

For reasoning, the project uses Anthropic Claude Sonnet 4 through GitLab Duo custom flows.

For measurable impact, we added a Google Cloud BigQuery layer that stores pipeline metric snapshots and generates an impact report. This makes the GitLab + Google story meaningful rather than decorative: GitLab Duo performs the workflow automation, and Google Cloud provides durable measurement and reporting.

Demo repository

We also built a purpose-designed demo repo with an intentionally wasteful CI setup so the optimization story is clear and testable. The baseline CI includes waste patterns like:

  • broad pipeline execution for small changes
  • repeated npm ci
  • no useful cache
  • large unnecessary artifacts
  • a docs-only MR still doing too much work

That let us demonstrate a highly visual “before vs after” improvement in a way judges can understand immediately.

Challenges we ran into

One of the biggest challenges was making the project feel truly autonomous without becoming unsafe.

Early on, the flow could analyze the merge request correctly, but the handoff between agents was fragile. The profiler was producing useful output, but the optimizer was not always receiving the right structured context to continue reliably. We had to debug the flow orchestration itself, improve the cross-agent handoff, and make sure the downstream components consumed machine-parseable output instead of loosely structured prose.

Another challenge was getting the UX right. There is a big difference between a “smart CI report” and a real workflow agent. A strong judge or real user will quickly ask: Does it actually do anything, or does it just comment? We had to tighten the prompts so the flow would proceed automatically in patch mode when the safety conditions were met, instead of stopping for unnecessary confirmation.

We also ran into a real Google Cloud integration issue: our original BigQuery write path used streaming inserts, and that collided with free-tier constraints. We redesigned the reporting path to use a batch load approach instead. That ended up being a better architectural choice and made the Google integration more robust.

The final challenge was balancing three goals at once:

  • autonomy
  • trust
  • measurable impact

If the flow is too aggressive, it becomes risky. If it is too cautious, it becomes a fancy lint report. Getting that balance right was one of the most important parts of the build.

Accomplishments that we're proud of

We are proud that this project is not just a concept. It is a working GitLab Duo flow that runs inside the GitLab AI Hackathon environment, reacts to a real merge request trigger, and performs a real automation workflow.

A few highlights we are especially proud of:

  • building a trigger-based GitLab Duo flow instead of a chat-only demo
  • creating a transparent Green CI Score instead of a black-box “AI says so” output
  • making the automation conservative and CI-only for trust and safety
  • adding a meaningful Google Cloud layer for measurable impact
  • showing a docs-only fast-path story, which is visually simple and very demo-friendly
  • designing the flow to either patch safely or fall back gracefully with a report
  • debugging the multi-agent handoff so the project behaved more like a real system than a prompt chain

We are also proud of the narrative clarity of the project. The story is easy to understand:

same merge request -> less waste -> fewer jobs -> safer CI changes -> measurable impact

That clarity is a huge part of what makes an automation product usable.

What we learned

We learned that the hardest part of agent workflows is not always the model capability. It is the system design around the model.

A good agent needs:

  • a clear trigger
  • the right context
  • narrow permissions
  • deterministic safety boundaries
  • measurable output
  • a graceful fallback path

We also learned that judges and users both care deeply about trust. It is not enough for an agent to be clever. It needs to be legible. Users need to understand what it changed, why it changed it, and how to undo it.

Another important lesson was that sustainability stories land much better when they are tied to practical engineering metrics. Saying “this is greener” is weak. Saying “this reduced unnecessary jobs, shortened runtime, and cut runner-minute usage” is much stronger.

Finally, we learned that GitLab Duo flows become much more compelling when they are framed as workflow agents instead of assistant personalities. The best experience here was not “ask AI a question.” It was “trigger AI in a real workflow, let it investigate, and get a concrete result back.”

What's next for Green CI Auto-Optimizer

The current version focuses on safe CI optimization for a clear repository contract. The next steps would be:

  • support more repository shapes and language stacks beyond the current demo contract
  • improve the optimization planner so it can adapt to more complex CI topologies
  • add stronger measured before/after reporting from live GitLab pipeline runs
  • support organization-level rollups for CI waste patterns across multiple repos
  • expand the Google Cloud reporting layer into trend analysis over time
  • offer configurable operating modes such as report-only, patch-only, or team policy mode
  • integrate more directly with sustainability reporting workflows for engineering organizations

Longer term, we see this becoming a reusable GitLab-native agent for teams that want faster pipelines, lower CI costs, less unnecessary compute, and better developer feedback loops without manually tuning .gitlab-ci.yml by hand.

Green CI Auto-Optimizer is our attempt to turn CI efficiency from a one-time cleanup task into an autonomous, repeatable workflow inside the SDLC itself.

Built With

Share this project:

Updates