rob thijssen
dff283c468
Builds crates/remote/Dockerfile from our mirror at git.lair.cafe rather than from GitHub, and resolves the version from the mirror's tags rather than GitHub's releases API. BloopAI has announced a sunset; the mirror exists so this build outlives them, which is pointless if the build still asks github.com what to build. Nothing in this image's path touches GitHub. Gitea mirrors carry tags but not releases, so latest is resolved by filtering to the strict release pattern v<semver>-<14-digit datestamp> and sorting on the datestamp -- which also skips the malformed historical tags in the upstream repo (vv.20250708094151, vv0.0.40-nbump.2....). FEATURES is deliberately left unset: the Dockerfile strips the private billing crate only when it is empty, which is the documented self-host path. Setting it would send the build looking for BloopAI/vibe-kanban-private over SSH, which we cannot reach. Consumed by the vibe-kanban quadlets on bob (kanban.internal). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TsmUEtbyTkgQ18tCFYXo1h
2.4 KiB
2.4 KiB
lair/containers
Container images required by lair infrastructure, built and published to the
Gitea registry at git.lair.cafe. Convention follows
gongfoo's images/ setup.
Layout
images/<name>/ one directory per image
Containerfile (when we author the image ourselves)
build.sh local build helper
readme.md what it is and how it's built
.gitea/workflows/
images.yml builds + publishes every image, on push / daily / dispatch
Images
| Image | Published as | Source |
|---|---|---|
| hermes | git.lair.cafe/lair/hermes:{version,latest} |
built from NousResearch/hermes-agent's Dockerfile at the latest release tag |
| vibe-kanban-remote | git.lair.cafe/lair/vibe-kanban-remote:{version,latest} |
built from our mirror BloopAI/vibe-kanban's crates/remote/Dockerfile at the latest release tag — deliberately never touches GitHub, since upstream is sunsetting |
How builds work
- Trigger: push under
images/**, a daily cron poll, or manual dispatch. - Release-tracking: each image job resolves the upstream's latest release via
its API and builds that exact ref. For upstreams that ship their own Dockerfile
(hermes) we build directly from the upstream git context; for images we author,
the version is passed as a
--build-argwith the Containerfile pin as fallback. - Self-healing: a build runs only when the resolved version isn't already in the registry — and because the registry (not a committed pin) is the source of truth, a failed build simply retries on the next poll instead of stranding a stale image. (Lesson borrowed from gongfoo.)
Adding an image
mkdir images/<name>, add aContainerfile(or build from an upstream context) +build.sh+readme.md.- Add a job to
.gitea/workflows/images.ymlthat logs in, buildsgit.lair.cafe/lair/<name>:latest, and pushes. - Consumers pull
git.lair.cafe/lair/<name>:latestwithAutoUpdate=registry.
Required secret
| Secret | Purpose |
|---|---|
REGISTRY_TOKEN |
Gitea token with write:package for git.lair.cafe; used as podman login -u $GITEA_ACTOR -p $REGISTRY_TOKEN. Set in this repo's (or the lair org's) Actions secrets. |
Build jobs run on self-hosted runners labelled metal + podman.