Hands-off Auction: issue in, production out

Open a GitLab issue and touch nothing. GitLab Duo agents plan, code, review, test, ship to staging and production, roll back failures, run incidents and report the carbon cost of every release.

Comment

Inspiration

Built for maintainers of small web apps who can't babysit every review, failed pipeline and release. Shipping a small change still needs a person to triage, code, review, watch CI, deploy and watch production. I wanted to see if GitLab Duo could carry the whole loop, safely, with nobody touching it. GitLab Duo does the work; deterministic CI decides when code may merge, deploy or roll back.

Starting point (Path B): hmellor's MIT-licensed auction-website provides the auction UI. Everything else, the post-code delivery and operations system (Duo flows, CI gates, automatic merge and promotion, monitoring, incident recovery, release evidence and SCI reporting), I built during this hackathon.

What It Does

You open an issue. Then:

  • Issue to MR flow: a triage agent labels, sizes and plans it, then a builder agent writes the code and tests and opens an MR
  • The pipeline runs lint, unit tests, build, Semgrep SAST, secret detection, a security gate (fails on any Critical/High finding or leaked secret), npm audit, and an SBOM + license check
  • Red pipeline: Pipeline Doctor fixes it (max 2 tries, then agent::blocked + needs-human)
  • Duo Code Review reviews the exact head commit. Merge happens only with a green pipeline AND a clean review of that commit. Any new commit means a new review. needs-human and agent::blocked always stop the merge
  • develop deploys to staging and runs smoke tests, then a release MR merges to main
  • Firestore rules integration tests (20 allow/deny cases against the Firebase Rules API) gate every deploy
  • Production deploys automatically and gets smoke-tested. If that fails it rolls back automatically, under the same production lock as deploys, and only ever reverts the release that failed. Each release is tagged as a GitLab Release with its package, SBOM, license report and carbon (SCI) report
  • Release Guardian posts a summary on the original issue and closes it

After release, production keeps running itself:

  • Every 30 minutes a monitor checks production. On failure it re-checks under the production lock, rolls back, and opens an incident with a diagnosis: the failing check, the Hosting release history, whether the bad release came from a pipeline or out of band, and health after the rollback. The agent writes the postmortem and closes the incident, or fixes the regression forward
  • Customer emails come in through Service Desk and get an agent reply
  • A weekly dependency audit opens an issue that the agents upgrade and ship
  • Daily Backlog Patrol grooms the backlog
  • A config-drift check reverts out-of-band Firebase rule changes and verifies the fix before closing
  • Pipelines and synthetic probes export traces, metrics and logs to GitLab Observability (OpenTelemetry), with alerts that email when production goes down or latency tops 3 seconds

When something can't be fixed safely (a review that isn't clean, recovery attempts used up, a failed gate), the loop stops and escalates with needs-human. It never merges on a red pipeline.

Proven Runs (no human touch)

  • Feature: issue #4 to production in 12 minutes, Oct 25, 2026, 16:07 to 16:19 PDT: MR !9, release MR !10, production pipeline, then summary and close. This run predates the exact-commit review gate, which shipped afterwards (Oct 26, 00:10 PDT)
  • Bug fix through the exact-commit review gate: issue #11 to production in 18 minutes, Oct 26, 2026, 10:32 to 10:50 PDT. Merge-bot requested Duo Code Review for head commit c29894cb at 10:37; the review came back clean at 10:38 and only then did MR !26 merge, followed by release MR !27 and the production pipeline
  • Dependency upgrade: audit issue #7 to agent MR !15 to release !16 to production
  • Incident drill: a bad out-of-band deploy at 20:46 PDT was caught and rolled back at 20:48, and the agent wrote the postmortem and closed incident #9 at 20:50
  • DORA (GitLab DORA metrics API, Oct 20 to Oct 25, 2026): 1.14 production deploys a day, median lead time 163.5 seconds from commit to production. That's separate from the 12-minute issue-to-production time above, which includes planning and coding

How I Built It

GitLab Duo Agent Platform custom flows in the AI Catalog (Issue to MR with triage + builder agents, Pipeline Doctor, Release Guardian, Backlog Patrol) plus the foundational Code Review Flow. GitLab CI/CD with workflow rules, resource groups, pipeline schedules, environments, incidents with timeline events, Releases, the Generic Package Registry, Service Desk, Issue Boards, Code Quality, JUnit and coverage reports, CycloneDX SBOM and GitLab Observability. Deploys go to Firebase Hosting on Google Cloud with no stored keys, via GitLab OIDC and Google Workload Identity Federation, limited to protected branches.

Challenges

  • Flows can't trigger other flows, and flow tokens can't merge. So the deterministic hand-offs (merge, release MR, Doctor mention, schedules) live in CI behind a masked token that exists only on protected main
  • Making autonomy safe was harder than making it work. An external review found that green-but-unreviewed MRs could merge, that a rollback could overwrite a newer healthy deploy, and that scanners couldn't block. I fixed all three: the review gate is bound to the head commit, the rollback to the failed release, and the security gate is blocking. On its first run, the new gate caught 3 Critical/High SAST findings that were then fixed

Accomplishments

After initial setup, an eligible issue reaches verified production without human approval, across all nine DevSecOps stages. Failed reviews or exhausted recovery attempts stop the loop and escalate with needs-human. Every claim is backed by visible pipelines, MRs, issues and Releases.

What I Learned

An agent you can trust is mostly guardrails: exact-SHA reviews, retry caps, shared locks, and failing loudly instead of reporting a success that didn't happen.

What's Next

Browser end-to-end tests of sign-in and bidding in the smoke stage, a server-enforced auction deadline, and carbon budgets on MRs.

Sustainability (Most Environmentally Impactful)

Every production release publishes its Software Carbon Intensity in its GitLab Release, computed by scripts/sci-report.mjs: SCI = ((E x I) + M) / R, with R = one production release.

  • E: runner time measured from the GitLab Jobs API, converted with a modeled 8.92 W per job (E_kWh = runner_minutes / 60 x 0.00892; 2 vCPU / 8 GB hosted runner, Cloud Carbon Footprint coefficients, 50% utilisation, PUE 1.1). 8.92 W is a model, not measured runner power
  • I: 575.77 gCO2e/kWh (Google Cloud us-east1, 2024)
  • M: host embodied carbon shared by time and vCPU
  • Boundary: every CI job, retry, Duo agent session job, monitor and merge-bot run. Excluded and declared: LLM inference inside Duo (no per-call energy is exposed), CDN serving, developer devices. So it shouldn't be compared directly with SCI figures that include inference

Results (modeled estimates from measured runner time): in the CI window from Oct 24, 17:00 to Oct 25, 22:32 PDT, covering five releases, 150 pipelines and 376 runner-minutes, the footprint averaged 8.2 gCO2e per release, versus 12.0 g for a modeled counterfactual where monitor and merge triggers run the full pipeline. That's about 31% less. For example, release v2026.10.26-0e424918 (Oct 26, 2026, 01:10 PDT) came in at 4.6 g versus an 8.7 g counterfactual (an estimated 47% less); every release's own figure is in its GitLab Release. These are modeled what-ifs, not measured before-and-after reductions.

Design choices behind it: dedicated monitor, ops and merge-bot pipelines skip the full build/test/deploy pipeline and run only the jobs their task needs; superseded pipelines are cancelled; the npm cache is keyed on the lockfile; triage and build run as two agents in one flow session; the app is a static CDN site with no always-on server; and incidents roll back first, so no fix-forward pipeline runs while users wait. If any carbon data read fails, the report fails instead of publishing a number.

Built With

Share this project:

Updates

Submission history