Most pipelines only ask one question: does the new build work?
In real incidents, the question that hurts is different: can we still run what we had before?
That idea became Undo — my entry for the GitLab Life After Code / Transcend hackathon on Devpost. It’s a small app with a big lifecycle: prove the previous package still boots, ask a human to approve, then promote to Google Cloud Run.
What Undo does
On every push to main, GitLab CI:
- Tests and packages the exact build
- Starts the previous package and hits /health (ROLLBACK_OK)
- Builds an image, runs Cloud Build into Artifact Registry, and deploys staging on Cloud Run
- A custom Duo flow — Undo — triggers on pipeline passed, reads the rollback proof, and opens a Work item (PASS or FAIL)
- I reply with one word: approve
- A manual promote_production job ships the same image to production
Live health check: https://undo-pjcvzfkkzq-nw.a.run.app/health
Supervised autonomy in practice: agents and CI do the middle work; a person still owns the final call.
Why GitLab made this possible
This hackathon isn’t “write a clever chatbot.” It’s about life after code — verify, package, release, configure, govern — with Duo Agent Platform in the loop.
What stood out for me:
- Pipelines as the spine — one .gitlab-ci.yml from test through staging and a visible promote gate
- Duo flows, not chat theatre — Undo runs on Pipeline events → Passed, then posts a Work item. No prompt from me mid-demo
- Everything in one place — code, packages, jobs, issues, and the agent session history judges can click through
- GitLab wasn’t just the host repo. It was the product surface I was building on.
Why Devpost helped (more than “submit here”)
Devpost keeps a solo hackathon sane: clear Path A / Supervised rules, a place for the story, try-it-out links, and a video deadline you can’t ignore.
The structure forced me to explain Undo the way judges will see it — not as a pile of YAML, but as a loop: prove → ask → approve → promote. That clarity made the build better, not just the form.
If you’re entering: treat Devpost as a design brief, not a last-minute paste box.
Why Google Cloud was the missing proof
A green pipeline is nice. A public URL is better.
Wiring GitLab CI to Google Cloud — service account, Cloud Build, Artifact Registry, Cloud Run staging and production — meant anyone can open /health and see the version we just approved. That’s the Google Cloud bonus path done properly: deploy config in the repo, human still on the gate.
Cloud Run gave me somewhere real to land. The app stayed tiny on purpose so the story stays on the lifecycle, not a fake product UI.
- What I’d tell another builder
- Event-driven flows beat chat demos for this challenge
- “Green” ≠ “safe to promote” until the previous artefact still answers
- Credits, group projects, and CI variables are part of the craft — budget time for them
- Ship a live URL if you can; it turns “I deployed” into “click this”
Links
Project (GitLab): shielyule-group/ShielYule-project
Live demo: https://undo-pjcvzfkkzq-nw.a.run.app/health
Hackathon: GitLab Life After Code on Devpost
Video: https://youtu.be/dI7f7ozZu6Y
Huge thanks to GitLab for the platform and the brief, to Devpost for a submission experience that keeps builders honest, and to Google Cloud for a place to prove the promote step in public.
Undo’s rule is simple: don’t treat the next package as ready until the last one still boots — and don’t promote until a human says so