Repo Board

A live GitLab issue board. Approve one plan, and GitLab Duo builds it, reviews it, and repairs failing pipelines. You read the summary and merge; GitLab CI deploys it to Cloud Run.

Comment

Inspiration

A coding agent can open a merge request in minutes. Then the work waits on a person: someone has to watch the pipeline, ask for a review, get the failure fixed, and decide whether the result is safe to ship. For a solo maintainer or a small team, that follow-through becomes its own queue.

I wanted to approve the intent once, let GitLab Duo carry the work after that, and come back to one decision, merge or not, with the evidence in front of me.

What it does

Repo Board puts a GitLab project's issues on a live board. Open issues start in Backlog. Once a person adds one to the board, it moves through six stages: Todo, In planning, Ready, In progress, In MR, and Done. GitLab stays the source of truth: the issues, plan comments, stage labels, merge requests, and pipelines all live there.

  1. Plan. An agent claims the issue through the board's WebMCP tools and posts a plan as a versioned comment on the issue.
  2. Approve. A person approves that exact plan version, for the current issue text, and picks who implements it: GitLab Duo or a local agent. This is the only approval before the merge.
  3. Implement. Repo Board starts the Duo Developer flow with the approved plan. Duo opens a draft merge request that closes the issue, and Repo Board binds it to the card.
  4. Review and repair. Repo Board asks Duo to review the merge request. If the pipeline fails, it starts Duo's Fix Pipeline flow, at most twice per approval. When Duo opens a fix as a separate merge request, Repo Board checks that Duo wrote it and that its pipeline passed, then lands it on the original branch.
  5. Readiness. Repo Board posts a readiness summary on the merge request and shows it on the card: pipeline result, repairs used, open review threads, SAST findings, size of the change, and how far the default branch has moved since approval. It doesn't call a merge request ready while GitLab would refuse to merge it, for example when a reviewer has requested changes.
  6. Merge and deploy. A person reads the summary and clicks Merge. The default-branch pipeline builds the container and deploys it to Cloud Run, and the card changes to "Merged and deployed" once the deploy job passes.

If the issue text or plan changes after approval, the approval goes stale and automation stops. Repo Board never merges into the default branch on its own.

How I built it

GitLab Duo Agent Platform. Repo Board starts the Developer flow (developer/v1) and the Fix Pipeline flow (fix_pipeline/v1) through the Duo Workflows API, using the approving person's OAuth token. It polls their status over GraphQL and links merge requests to runs through duoWorkflowLinks. It requests code review by adding the Duo reviewer. AGENTS.md and .gitlab/duo/agent-config.yml give Duo's sandbox Node 24, pnpm, and the project's rules, so Duo runs lint, typecheck, and the unit tests before it opens a merge request.

The app. TypeScript, React, Fastify, and Postgres. Every board change goes through one pure reducer, with an expected revision and an action ID, so retries and concurrent tabs never apply a change twice. WebSockets keep open tabs current. The project's role can't create webhooks, so Repo Board polls GitLab every minute and reconciles from GitLab's state rather than trusting events.

CI/CD and Google Cloud. GitLab CI runs lint and typecheck, unit and Postgres-backed tests, a build and smoke check, SAST, and Secret Detection. It then builds the container into Artifact Registry and deploys it to Cloud Run with a health check. OpenTofu defines Cloud Run, Cloud SQL, Secret Manager, Artifact Registry, Cloud Scheduler, and the service identities. CI signs in to Google Cloud through Workload Identity Federation, with no service-account keys.

I built it with Claude, using Codex as a subagent.

What changed for this hackathon

Repo Board started as an MIT-licensed board for GitHub on Cloudflare Workers, where agents claimed tasks from a browser tab through WebMCP. During the submission period, on or after October 5, I replaced the backend with Fastify and Postgres and moved the tasks onto GitLab issues. I also built the whole post-code workflow: approval, Duo dispatch, review requests, pipeline repair, readiness, and merge. GitLab CI/CD, the OpenTofu infrastructure, and the Cloud Run deployment are new too. The WebMCP tools, per-tab claims, and live updates carried over.

Original project: https://github.com/zac/webmcp-repo-board/tree/webmcp-challenge-v1

Challenges

  • No webhooks. The project's Developer role can't create them, so the board polls and reconciles instead of assuming every event arrives.
  • Fixes arrive as separate merge requests. Duo's Fix Pipeline flow opens a stacked merge request instead of pushing to the failing branch. Repo Board gives it its own identity and pipeline check, and lands it only after it passes.
  • Telling Duo's commits from a person's. The merge request author and pipeline user are the approving person even when Duo wrote the code, so attribution uses the commit author instead.
  • Knowing when to stop. A green pipeline isn't enough. Requested changes, a stale approval, or any other GitLab merge blocker stops the card short of "Ready to merge".

Accomplishments

Repo Board manages its own public GitLab project, and the live board shows real runs:

  • #2 "Add a favicon" and #5 "Say '1 file', not '1 files'" went from an approved plan to a Duo merge request, review, and readiness summary, then were merged and deployed.
  • On #5 and #3, the first pipelines failed in the image build. Repo Board started Duo's Fix Pipeline flow without being asked. Duo traced the failure to our Google Cloud identity configuration, not the code, and said so instead of changing code to force a pass. I fixed the configuration and reran the pipelines.
  • On #3 "Close the task drawer with Escape", Duo's code review found three real problems with suggested fixes. After they were applied, the pipeline passed, but the card still shows the merge as blocked, because Duo's review is still marked "changes requested".

What I learned

The hard part of life after code is keeping the approval, branch, pipeline, and review state in step while each one changes on its own. Good automation makes progress without being asked, and makes it obvious why it stopped.

What's next

Group-level boards, a pause control for a single issue, and a CSV export of delivery history.

Built With

Share this project:

Updates

Submission history