Inspiration

Teams hesitate to let an AI agent fix failing code. Typical agents can run any command, edit any file, or push over a colleague's work. Showcase asks a narrower question: how much of the post-code lifecycle can GitLab Duo handle if the agent gets almost no power and every step leaves evidence?

What it does

Showcase is a Supervised-autonomy project (Path A, Start Fresh) built on GitLab Duo Agent Platform. A person approves the outcome: they review and merge the MR and they press the manual production job. Duo and the pipeline do the steps in between.

  • Plan. The issue-planner flow reads one issue and posts one draft plan: problem, acceptance criteria, likely files, risks, test plan and lifecycle stages touched. It has two tools, both pinned to this project, and it can only comment.
  • Create. The guarded repair flow (Catalog item 1016320, version 1.1.3) fixes a failing application test in an open MR. The agent can read and edit one proposal file and run one trusted guard script. The guard reproduces the failure, tests the proposal in a Bubblewrap sandbox against tests from main, and publishes a single-parent commit with a Git lease. The MR stays open for human review.
  • Verify, Secure, Package. Every MR runs unit tests, 55 guard contracts, 115 release-tool tests, Semgrep SAST, secret detection, a security gate (any finding blocks packaging) and a checksummed release archive.
  • Configure and Govern. config_check keeps deployment, monitor and flow configuration consistent, and warns when a flow definition has no recorded live acceptance. compliance_check enforces the MIT license, keeps scanner jobs from being weakened, keeps production manual and checks DCO sign-off.
  • Release. main deploys to Cloud Run staging automatically. Production is a manual job that promotes the staged image digest.
  • Monitor. monitor_production checks /health and /version on both services and reports runtime drift against main, on a six-hour schedule. The first run left to the timer (pipeline 2989563007) was green: both services healthy and no drift.

Every stage is listed with its proof, and every gap is listed too, in docs/lifecycle-stages.md.

How we built it

Node.js 24 service, Python release and guard tooling, GitLab CI, two Duo Catalog flows defined in YAML in the repo, Bubblewrap for the sandbox, and Google Cloud Run for staging and production. The threat model (docs/threat-model.md) maps each control to a contract test.

Challenges

  • Keeping the agent useful with three tools. The guard, not the prompt, enforces the limits.
  • Live runs behave differently from tests. One repair session used both of its two attempts, and the planner overran its word limit (362 words against 350, then 316 against 300). We lowered the limit, re-ran it live, and recorded that it is guidance, not enforcement.
  • Recovery. A drill deliberately failed after a production promotion, restored the baseline traffic and digest, and verified health.

Accomplishments

  • Nine DevSecOps stages, each tied to a recorded run.
  • Live repair commits with all seven MR jobs green and zero SAST and secret findings.
  • Staging and production live on Google Cloud Run, with a manual production gate and a recovery drill.

What we learned

Narrow tools plus a trusted guard make an agent easier to trust than a clever prompt. Writing down what was not verified made the rest of the claims more credible.

What's next

  • Show the monitor going red against a real outage. Down and drift are covered by unit tests, but we have not watched either fail live.
  • Ask a Maintainer to require successful pipelines before merge and to protect main and the production environment (docs/hardening.md). The project account is Developer level, so these controls are not applied yet.
  • Move toward Hands-off only where a gate can enforce the limit, not where a prompt asks for it.

Links

Built With

  • bubblewrap
  • gitlab
  • gitlab-ci/cd
  • google-cloud-run
  • node.js
  • python
  • semgrep
  • yaml
Share this project:

Updates

Submission history