Phase 1 of the registry consolidation rolling out across the homelab —
infra/docs/plans/2026-05-07-forgejo-registry-consolidation-plan.md.
* New .woodpecker.yml builds + dual-pushes to
registry.viktorbarzin.me:5050/beadboard AND
forgejo.viktorbarzin.me/viktor/beadboard.
* GHA build-and-deploy.yml renamed to .disabled — would otherwise
race the Woodpecker build and clobber Forgejo with a stale image
during the bake. Re-enable only on rollback.
* No deploy step yet — Phase 3 flips infra/stacks/beads-server/main.tf
image= reference; pods still pull from registry.viktorbarzin.me
through the bake.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
## Context
BeadBoard does not yet have a container image or a CI pipeline that
produces one. The infra pattern (see `infra/.claude/CLAUDE.md` →
"CI/CD Architecture") is GHA builds + Woodpecker deploys: GHA builds
the image on every push to the default branch, tags it with the
8-character git SHA, and POSTs the tag to Woodpecker to trigger a
`kubectl set image` roll-out.
We follow that exact pattern here, mirroring `broker-sync`'s
`.github/workflows/ci.yml` (the closest functioning example) but
targeting the private `registry.viktorbarzin.me:5050` registry that the
cluster's containerd `hosts.toml` rewrites to the LAN IP for
pull-through.
## This change
### `Dockerfile`
- Three-stage build using `node:20-alpine`:
1. `deps` — `npm ci` (with devDeps) so the builder has TypeScript
and ESLint available during `next build`.
2. `builder` — runs `npm run build`; `NEXT_TELEMETRY_DISABLED=1` to
suppress the telemetry prompt in CI logs.
3. `runner` — copies only `.next`, `public`, `node_modules`,
`package.json`, and `next.config.ts`; runs as a non-root user
(`nextjs:1001`).
- `CMD ["npm", "start"]` invokes Next.js' production server on port 3000.
- `next.config.ts` does not opt into the `output: 'standalone'` build,
so we ship the full `node_modules`. We can trim to standalone in a
follow-up once we confirm all route handlers and SSE endpoints work
with the standalone tracer.
### `.dockerignore`
- Excludes `.git`, `node_modules`, `.next`, `.beads`, docs, reference
materials, Remotion assets, and local env files so the build context
stays small. `.beads` is sensitive (contains the local Dolt snapshot).
### `.github/workflows/build-and-deploy.yml`
- Triggers on `push` to `main` / `master` (upstream uses `main`;
`master` added so the fork's current branch also publishes).
- `build` job: buildx, login to the private registry via
`REGISTRY_USERNAME` / `REGISTRY_PASSWORD` secrets, then
`docker/build-push-action@v6` for `linux/amd64`, tagging both
`:<8-char-sha>` and `:latest`. GHA layer cache (`type=gha`) is wired.
- `deploy` job: POSTs to Woodpecker's `/api/repos/<id>/pipelines`.
`WOODPECKER_REPO_ID` is deliberately set to the literal string `TBD`
with a guard — the repo needs to be registered with Woodpecker before
the deploy step can fire. Until then the workflow reports success
with the image tag so the upstream image is still published. The
pattern, retry loop, and numeric-repo-id convention are lifted from
`broker-sync/.github/workflows/ci.yml`, which is the canonical
example in the infra migration doc.
## What is NOT in this change
- No `.woodpecker/deploy.yml` yet — that lives in the infra repo per
convention (infra serves the deploy step via `kubectl set image`
against the cluster SA). The orchestrator will register the repo
and land the deploy side.
- No standalone Next.js build. `output: 'standalone'` changes the
working directory layout enough to warrant a dedicated follow-up.
- No smoke test on the image. The existing `npm run test` gate
guarantees code-level correctness; container smoke-tests can be
added if the image breaks in production.
## Test Plan
### Automated
The GHA workflow itself cannot be exercised locally. YAML parses as
valid GitHub Actions syntax (same shape as `broker-sync/.github/
workflows/ci.yml` which currently runs green). The Dockerfile has
not been built in this commit to avoid dragging a ~700 MB node image
into a local session; the orchestrator should build it in CI first
or with:
```
docker buildx build --platform linux/amd64 -t beadboard:local .
```
Test suite still green:
```
$ node --import tsx --test tests/components/shared/left-panel-filtering.test.ts \
tests/components/shared/dispatch-button.test.tsx \
tests/lib/dispatch-prompt.test.ts \
tests/api/agent-dispatch-route.test.ts \
tests/api/agent-status-route.test.ts \
tests/lib/parser.test.ts \
tests/components/shared/left-panel.test.tsx \
tests/components/shared/unified-shell-hide-closed-contract.test.ts
# tests 40 pass 40 fail 0
```
### Manual Verification
1. Set repo secrets on GitHub: `REGISTRY_USERNAME`, `REGISTRY_PASSWORD`,
`WOODPECKER_TOKEN`.
2. Push to `master` (or `main`).
3. Expected: `build` job succeeds; image appears at
`registry.viktorbarzin.me:5050/beadboard:<sha>`.
4. `deploy` job: with `WOODPECKER_REPO_ID` still `TBD`, logs the image
tag and exits 0. Once the repo is registered, replace `TBD` with the
numeric id and the deploy will trigger the cluster roll-out.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Added a comprehensive code quality agent named 'Code Custodian' that identifies and fixes issues in the codebase, including test coverage, linting, documentation, and deprecated API usage.
