-
-
Pulse Release Agent — hands-off DevSecOps workflow built on GitLab Duo and GitLab CI.
Inspiration
Software delivery is much more than writing code. After a change is created, someone still has to plan the work, verify the implementation, run tests, check security, package the application, prepare a release, monitor the result, and decide whether the final state is safe enough to accept.
Pulse Release Agent was built to make that process more autonomous without removing accountability.
What it does
Pulse Release Agent is a hands-off DevSecOps agent built around GitLab Duo and GitLab CI.
An owner starts with an intent in a GitLab work item. From there, the system can:
- create a structured execution plan
- perform bounded code changes
- create branches and merge requests
- run verification and tests
- package the application into an immutable container
- run security scanning
- generate a CycloneDX SBOM
- create release evidence
- monitor the released runtime
- evaluate governance policies
- detect failures
- diagnose root causes
- apply a bounded repair
- rerun verification, monitoring, and governance
The project demonstrates all 9 lifecycle stages:
Plan → Create → Verify → Package → Secure → Release → Configure → Monitor → Govern
Each stage is backed by auditable evidence in the GitLab repository and CI history.
How we built it
The project uses GitLab Duo Agent Platform flows together with GitLab CI/CD.
We created two primary Duo flows:
- Pulse Release Planning Flow — converts an owner work item into a structured release execution plan.
- Pulse Bounded Code Change Flow — performs scoped repository changes, creates a branch and merge request, and leaves verification to GitLab CI.
The application itself is a small FastAPI service with /, /health, and /version endpoints.
The CI/CD workflow includes:
- pytest
- Ruff
- container packaging
- GitLab SAST
- Secret Detection
- Dependency Scanning
- Container Scanning
- Bandit
- Gitleaks
- pip-audit
- Trivy
- CycloneDX SBOM generation
- release provenance
- runtime monitoring
- governance evaluation
The first release, v0.1.0, is tied to an immutable container digest and structured release evidence.
Challenges we ran into
The main challenge was designing autonomy without simply giving an agent unlimited permissions.
We wanted the agent to be useful, but also bounded and auditable.
That meant separating planning from execution, preserving manual merge control, keeping security gates intact, recording provenance, and proving that recovery was real rather than simulated.
A second challenge was validating autonomous recovery. We deliberately introduced a safe health-contract mismatch so that GitLab CI would fail for a real reason. The agent then had to diagnose the exact expected-versus-actual difference and repair the application without deleting the test or weakening policy.
Accomplishments that we're proud of
The project demonstrates all 9 lifecycle stages defined for the hackathon:
Plan, Create, Verify, Package, Secure, Release, Configure, Monitor, and Govern.
The strongest result is the controlled failure and autonomous recovery flow.
We intentionally changed the /health response from:
status = ok
to:
status = degraded-demo
The real CI pipeline failed.
The agent inspected the failed test, identified the root cause, restored the correct contract, and reran verification, monitoring, and governance.
The final pipeline returned to green.
Owner intervention during the recovery: 0.
We also implemented:
- immutable release provenance
- GitLab-native security scanning
- fallback security tooling
- CycloneDX SBOM generation
- runtime monitoring
- governance evidence
- structured audit artifacts for every lifecycle stage
What we learned
The biggest lesson was that autonomous software delivery needs more than code generation.
Trust comes from:
- clear boundaries
- reproducible verification
- immutable artifacts
- explicit security policy
- monitoring
- governance
- evidence
- recovery
A hands-off agent becomes much more useful when every autonomous action can still be inspected after the fact.
We also learned that human control is most valuable at the right boundary. The agent can plan, execute, verify, monitor, and recover autonomously, while the owner still keeps the final merge decision.
What's next for Pulse Release Agent
The next step is to extend the same workflow to real deployment environments and additional release targets.
Future versions could add:
- external production deployment
- multiple environment promotion
- richer rollback logic
- deployment health checks
- approval policies by risk level
- broader release targets
For this Path A submission, external deployment is intentionally not required. The focus is on proving the autonomous GitLab-native lifecycle itself: planning, bounded execution, verification, security, release, monitoring, governance, and recovery.
Log in or sign up for Devpost to join the conversation.