linkding After Code: a GitLab Duo co-maintainer

One maintainer, millions of installs. GitLab Duo agents triage issues, prove each bug with a failing test before fixing it, guard user data on upgrade, and ship to Render after one approval.

Comment

Inspiration

linkding is a self-hosted bookmark manager with 11k+ GitHub stars, about 10 million Docker pulls, 190 open issues, 45 open pull requests, and essentially one maintainer. His contributing guide says he may ignore pull requests he doesn't want to maintain. That's honest, and it shows the real bottleneck: not writing code, but everything after it. Triage, reproducing bugs, making sure an upgrade never damages years of someone's data, releasing, deploying, and recovering when something breaks.

What it does

We moved linkding to GitLab and built a lifecycle co-maintainer on GitLab Duo Agent Platform, at the Supervised level. The maintainer makes only two decisions, which bug to fix (by assigning it) and whether the result ships (by approving the MR). Everything in between runs on its own:

  • Triage agent: labels every new issue using the maintainer's own rules (SCOPE.md), links duplicates, asks for missing details, and politely parks large features. Issue text is treated as data: our prompt-injection test (#4) was noticed and ignored.
  • Reproduce-first fix agent: when a bug is assigned, it first commits a failing regression test (a red pipeline), and only then the fix and an MR with the evidence. Real upstream bug #6 (URLs with underscores rejected) went from issue to red test to fix to production in MR !3. A report that no longer reproduces (#7) gets "could not reproduce" and no guesswork fix.
  • Upgrade check on every change: CI starts the last official release, seeds it with 54 tricky bookmarks, upgrades the same database to the new build on SQLite and Postgres, and compares every value and every table's row count. No LLM decides this; it's a plain comparison. A migration that passes every unit test but blanks users' notes is blocked (MR !4, staged).
  • Secure: SAST, secret detection, dependency and container scanning, plus Duo Code Review with linkding-specific rules. An XSS regression is caught by upstream's own test and the review (MR !5, staged). Code Review also found a real rollback bug in our own deploy script (MR !2).
  • Package, release, deploy: the exact tested image is tagged with the version, a GitLab Release is created from agent-written notes, the database is backed up, and the image is deployed to Render and verified on the live site.
  • Monitor and recover: if verification fails, CI rolls Render back to the previous deploy and opens an ops::alert issue, which triage picks up (MR !8, then #8). Upstream changes arrive as sync MRs through the same checks (MR !7).

All nine stages are covered: Plan, Create, Verify, Package, Secure, Release, Configure, Monitor, Govern.

How we built it

  • Three custom flows (triage, fix, release notes), each with its own service account, triggered by issue creation, mentions, assignment and MR creation; plus Duo Code Review with custom review instructions and an agent skill (linkding-regression-test).
  • Agent environment: a setup script installs linkding's test toolchain so agents can run the tests, behind a network allowlist.
  • GitLab CI/CD: lint, tests, the upgrade check (Python scripts against linkding's REST API), four security scanners, versioning, releases, and a deploy-verify-rollback chain using Render's API.
  • Guardrails (Govern): agents have no merge tool, and the maintainer's approval is required. A guard job, loaded from the target branch so a branch can't weaken it, fails any agent commit that touches the pipeline, the agents' own rules, migrations or dependencies. CODEOWNERS covers the same paths. Deploy credentials are protected variables, so only main can deploy, and every agent commit is attributed to its service account acting for the maintainer.

Challenges we ran into

  • Finding a place to deploy: Google Cloud required a prepayment, and our AWS account turned out to be an organisation sandbox that blocks EC2. We moved to Render's free tier, deploying the image CI built through Render's API.
  • A restricted role: we couldn't enable pipeline variables or create project tokens. Schedules are recognised by their description instead, and the rollback demo is triggered by a tag in the MR title.
  • Real-world surprises the pipeline caught: Render runs PostgreSQL 18, so the backup job's pg_dump 16 refused to run. The failed backup stopped the pipeline before the deploy, so production was never at risk, and the fix was one line.

Accomplishments that we're proud of

  • An agent fixed a real upstream bug end to end, with a failing test as proof, and it's live in production.
  • Duo Code Review found a genuine bug in our own rollback logic, which we fixed before merging.
  • The upgrade check catches data loss that no unit test sees, and it doesn't depend on an LLM.

What we learned

Agents become trustworthy when their work comes with evidence: a red test before a fix, a deterministic upgrade report, a reviewable MR. Guardrails have to live outside the agent's prompt, in CI and branch rules, where the agent can't change them.

What's next

Offer the underscore fix back upstream, add a candidate (canary) service before production, extend the upgrade check to files on disk, and enforce the guard with a pipeline execution policy.

Honest limits

S4 (destructive migration), S5 (XSS regression) and the prompt-injection issue are staged demos, labelled as such. The other demo issues are real upstream reports, credited to their reporters. linkding itself is MIT-licensed by its author; our additions are the automation, the pipeline, and the fix agents' changes.

Built With

Share this project:

Updates

Submission history