Inspiration
Most agent demos stop once the code is written. Releases still break after that, and someone has to notice, roll back, file an incident, and write a fix. Aftercare automates that post-release loop. A human still makes the final call at the merge gate.
What it does
Aftercare runs one recovery pass on a release (v2-bad) that fails its health check:
-Deploy: the bad release becomes active (simulated: a state change in the repo). -Detect: the health check returns 500. -Roll back: the active release returns to the last known good version (v1) in state/state.json. -Verify: the health check returns 200 on the active version. If the state file doesn't match, the pipeline fails. -Incident: an incident issue is opened with the evidence. -Fix Author: a GitLab Duo Agent Platform flow opens a fix merge request that references the incident. -Fix Reviewer: a comment-only review checks that only the expected release folder changed, that the health check returns 200, and that the merge request references the incident. It posts its result on the merge request. The human gate is the merge. The agents never merge. A person marks the merge request ready and merges it. The pipeline is not re-triggered by the merge.
Autonomy level: Supervised. The human approves the outcome, not each step.
How we built it
-Python CLI (scripts/aftercare.py): runs the seven steps and exits 0 only when every step passes. -GitLab CI job (.gitlab-ci.yml): runs on manual pipelines only, uses a python:3.12-slim image, and keeps the artifacts for 30 days. -Telemetry: structured JSON lines in artifacts/telemetry.jsonl, plus a summary in artifacts/latest-run.json. -Tests: 24 unit and acceptance tests, passing with and without the API token set. -Credentials: a project CI/CD variable holds the API token. The job falls back to CI_JOB_TOKEN for the incident step.
Challenges we ran into
-Scope change: the first plan used Google Cloud, with Workload Identity Federation and Cloud Run rollbacks. We dropped it so the project would not depend on a cloud account. The environment is labeled simulated, and we give up the Google Cloud bonus. -Autonomy choice: we did not claim Hands-off. We could not confirm that a flow can approve or merge safely, so the human merge gate stays. -Re-triggering: an early version ran on every push to main. Each merge started a new recovery, which opened a new incident. The job now runs only on manual pipelines. The fix is a placeholder. The fixed release makes the health check return 200. It shows the workflow, not a real code repair.
Accomplishments that we're proud of
The full loop runs end to end on the Showcase main branch: a bad release is detected, rolled back, an incident is opened, a fix merge request is created, and a reviewer comments on it.
- The human merge gate works: a person marked the merge request ready and merged it, and the pipeline did not run again afterward.
- Failures are loud: the pipeline fails if verification or incident creation fails.
Lifecycle coverage: deploy and monitor (detect, roll back, verify), plan (incident issue), create (fix merge request), and verify (automated review
What we learned
The gate matters more than the agent. A draft merge request plus a manual merge is a simple, enforceable human checkpoint. Triggers need strict scope. A push trigger that runs on merge can start a loop. Fail loudly. A rollback counts as successful only after the state file and health check confirm it.
What's next for Aftercare: Supervised release recovery in GitLab CI
- Replace the placeholder fix with a real code change that the agent proposes and a test verifies.
- Add failure scenarios beyond the single v2-bad release.
Log in or sign up for Devpost to join the conversation.