Cooper

• 

  Cooper surveys a GitLab group on the nine DevSecOps stages: 6 projects, 6 ways to deploy, 67% never scanned.

• 

  The standard is learned from patterns across all projects: each choice keeps what the healthiest projects do, with its reasoning.

• 

  The born project's real pipeline: tests, image, four scanners, staging, validation, production, smoke test, rollback armed.

• 

  The new project, live: a starter page with the request, the inherited lifecycle and the commit and pipeline that built it.

• 

  Cooper runs the same lifecycle on itself, from tests and scanners to staging, production and a smoke test.

• 

  One Duo Agent Platform session, three agents: midwife decides what to build, gatekeeper clears the merge, herald reports it live.

Inspiration

Every company that has written software for a few years has the same problem. Each team picked its own stack, its own pipeline and its own way to ship. Code is the easy part now; what most internal projects lack is a life after code: tests that run, scanners, a staging step, a way back when production breaks. Platform teams cannot hand-hold hundreds of projects one at a time.

What it does

1. Survey. Cooper reads every project in a GitLab group and scores it on the nine DevSecOps stages, from evidence it can prove: CI jobs, templates, project settings, files. In our seed group of six projects it found six ways to deploy, and two thirds never scanned.
2. Standard. Cooper does not copy one favourite project. For every choice (how to deploy, how to test) it groups all projects by what they do and compares their health, then keeps the choice whose projects are healthiest among the ones it can run end to end. Every line of the standard comes with its reasoning.
3. Birth, hands-off. Someone opens an issue (New dashboard: Open support tickets per team) and mentions Cooper. Three agents on the GitLab Duo Agent Platform take it from there:
   • the midwife reads the issue and decides what to build (kind, name, owner) and files a birth request
   • Cooper's pipeline creates the project; its lifecycle arrives as a merge request whose pipeline runs tests, the container build and four GitLab scanners (SAST, dependency, secret, container)
   • the gatekeeper reads the results and files the merge only when the pipeline is green with no critical findings
   • main deploys to staging, validates it, promotes to production and smoke-tests it with rollback armed; the merge tags a release and applies an approval rule
   • the herald posts the live link back on the issue

The new project starts as a live starter page: the request, the inherited lifecycle, and the commit and pipeline that built it. The team replaces the page with the app; every change after that ships the same way.

How we built it

• A Python CLI (cooper) for the survey, scoring, standard synthesis, project birth and the inherited pipeline (.gitlab/ci/inherited.yml, generated and checked by a test).
• A custom flow (Flow Registry v1) with three agent components, running in a Python 3.13 workload (.gitlab/duo/agent-config.yml) with Cooper installed, so the agents call small deterministic helpers (cooper find-project, mr-status, main-status) instead of improvising polling loops.
• The agents never hold a credential. Flows do not receive CI/CD variables, so the agents decide and commit each decision as a small JSON request to the cooper/requests branch. Cooper's own pipeline acts on it with its token, re-checks it (a merge is refused unless the MR pipeline is green with no critical findings) and reports back on the issue. Every decision is a commit, so the audit trail writes itself.
• Born apps and Cooper's dashboard are served from GitLab Pages: staging under its own path, validated by a health check that must serve the exact commit before production is promoted.
• Cooper runs the same lifecycle on itself: nine of nine stages, public pipeline history.

Challenges we ran into

• Flows cannot see CI/CD variables. The request-branch hand-off solved it, and it turned out to be the better security design.
• In the workspace, Pages defaults to members-only and pipeline variables are disabled. Born apps are pulled into Cooper's public Pages build instead of being triggered with variables.
• Restricted tokens and anonymous rate limits: every read falls back to public data.

Accomplishments that we're proud of

• A real hands-off loop: issue to live production with nobody in between, run more than once on gitlab.com, every step visible on the issue and in cooper/requests.
• A standard that explains itself: each choice cites how healthy the projects that make it are.

What we learned

• Giving agents decisions instead of credentials makes them easier to trust and to audit.
• Scoring from evidence (a CI job, a template, a setting) keeps every number on the dashboard explainable by a link.

What's next

Retrofit as a hands-off flow (a merge request that gives a legacy project the standard), deploy recipes for Kubernetes and Cloud Run when a group provides credentials, and a scheduled survey that opens issues for the projects that need it most.

Built With

• container-scanning
• dependency-scanning
• docker
• gitlab-ci
• gitlab-duo-agent-platform
• gitlab-pages
• gitlab-sast
• python
• secret-detection