Issue to Live Site

A food pantry volunteer opens a GitLab issue in plain English. GitLab Duo agents and pipelines plan, test, scan, review, release and verify it live, with nobody else touching it.

Comment

Path A (Start Fresh) · Hands-off · all nine DevSecOps stages

Inspiration

Small nonprofits (food pantries, tenant unions, mutual-aid groups) run websites their volunteers can't safely change. Hours go stale, holiday closures go unannounced, and the one person who knew how to deploy moved away. Wrong hours on a food pantry's site mean someone takes two buses to a locked door.

47.9 million people lived in food-insecure households in the US in 2024 (USDA ERS), Feeding America's food banks work with 60,000+ pantries, meal programs and agencies, and about half of those partner agencies (51%, Hunger in America 2014) had no paid staff at all. There is no webmaster.

What it does

A volunteer opens an issue in their own words, for example "We're closed Thursday Nov 26 for Thanksgiving, open Wednesday 9 to 1 instead." That is the only thing a person does. Then:

  1. Plan. A work item trigger starts our volunteer-site-request flow. Its gatekeeper agent checks that the author is a registered volunteer (the project is public, so anyone can open an issue). Its triage agent reads the content policy and the content files and posts a plan with the exact entries, a release note and a phrase the live check must find, or refuses kindly (a request naming a client is refused and the issue is made confidential), or hands it to a person.
  2. Create. The editor agent makes the smallest edit to the site's data files and opens a merge request.
  3. Verify and Secure. The merge request pipeline builds the site and checks content schemas, HTML, links and accessibility (axe, WCAG 2.2 AA, with screenshots posted to the merge request), runs GitLab SAST, Secret Detection and Dependency Scanning behind a security gate, runs a deterministic content-policy check, and starts our policy review agent, which checks the diff on its own.
  4. Review and fix. The pipeline starts GitLab's Code Review flow, which must approve. If it asks for changes with suggestions, the pipeline applies them and everything runs again; other failures get one attempt from GitLab's Fix CI/CD Pipeline flow. Policy or security failures always go to a person.
  5. Merge, package, release. The merge job checks the volunteer list again and turns on GitLab auto-merge for the exact commit it tested. The release pipeline packages the site once into the Package Registry, deploys that package to staging, checks it, deploys the same bytes to production through a version pointer in a separate public GitLab Pages project, and checks the public URL.
  6. Monitor. If the live check fails, the pipeline rolls back to the last release, opens an incident and starts our incident agent, which writes the report. An hourly uptime check opened and resolved incidents on its own (switched off for judging).
  7. Report and govern. A GitLab Release is created with an evidence record (who asked, which agents acted and their measured model usage, which checks passed, the package checksum, deployments and live checks), and the volunteer gets a comment with the live link and the time from request to live. The issue closes.

Real runs: the Thanksgiving hours in the video went from issue to verified live in 8.8 minutes, holiday volunteer shifts in 10.2 minutes, a wishlist change in 8.4 minutes; a thank-you post naming a client was refused in 49 seconds and hidden; a fire drill shipped a broken home page on purpose and the pipeline rolled it back and opened an incident with an agent-written report.

How we built it

  • Three custom flows defined in YAML in the repo (.gitlab/duo/flows/), created as PRIVATE AI Catalog items and enabled with their trigger by scripts/sync_catalog.py. Each flow gets only the tools the policy file allows; a configure job fails the pipeline otherwise.
  • GitLab only lets a person's action fire a trigger, and a flow can't start another flow (we tested start_flow; it is refused). So the issue fires the first flow, and the pipeline starts the rest over the REST API at its gates and reads their verdicts.
  • The site is Eleventy with content in YAML and Markdown, so agent edits are small and reviewable; every link is relative, so one package works at staging and production.
  • Configuration as code with OpenTofu, the GitLab provider and GitLab-managed Terraform state (labels, environments, the request board, the uptime schedule).

Challenges we ran into

  • GitLab Pages on our entry project was members-only and our role couldn't change it, so we built a separate public host project that only publishes versioned packages (each commit there is one deployment).
  • Right after a deploy, Pages kept serving older files for a few minutes. Our first fire drill's live check passed on a stale page; we restored by hand, made every page carry its version, and the rerun rolled back on its own.
  • GitLab Duo Code Review posts its verdict a little after its session ends, and once asked for a real change our pipeline couldn't apply yet. Now the pipeline waits for the verdict and applies the reviewer's own suggestions.
  • Two merges landing a minute apart: GitLab cancels the older pipeline on main, so releases now report on every request merged since the last release.

Accomplishments we're proud of

A volunteer's sentence becomes a verified live change in about ten minutes with no human approval, while staying safe: two independent locks on who may publish, refusals that protect the person named, a security gate that caught real findings in our own code, and a rollback proven by a drill.

What we learned

Hands-off needs more than agents: it needs deterministic gates around them, an honest live check on the real URL, and a record of what happened. Measuring each session's model calls made cost visible per request.

What's next

A pipeline execution policy so the guardrails live outside the repository the agents edit; a form-based front door for volunteers who don't use GitLab; translations of the site, reviewed the same way.

Links

The pantry, its address and every person in the demo are fictional. AI tools used: Claude Code (coding assistant), the GitLab Duo Agent Platform (the request, policy review and incident flows, plus GitLab's Code Review and Fix CI/CD Pipeline flows), ElevenLabs (video narration).

Built With

  • axe-core
  • elevenlabs
  • eleventy
  • gitlab
  • gitlab-ai-catalog-custom-flows
  • gitlab-ci/cd
  • gitlab-dependency-scanning
  • gitlab-duo-agent-platform
  • gitlab-duo-code-review-flow
  • gitlab-duo-fix-ci/cd-pipeline-flow
  • gitlab-environments
  • gitlab-flow-triggers
  • gitlab-managed-terraform-state
  • gitlab-package-registry
  • gitlab-pages
  • gitlab-releases
  • gitlab-sast
  • gitlab-secret-detection
  • gitlab-terraform-provider
  • html-validate
  • node.js
  • opentofu
  • playwright
  • pnpm
  • python
Share this project:

Updates

Submission history