Go to file

images / hermes (push) Failing after 9m0s

Details

vibe-kanban-remote: move the build to lair/vibe-kanban

This repo is for third-party images built from someone else's source. We
now own a fork at lair/vibe-kanban, so its image is built there, next to
the code, by .gitea/workflows/container.yml. The quadlets move with it.

Leaving this job here was actively harmful, not just redundant: it built
from the BloopAI mirror and pushed to the same
git.lair.cafe/lair/vibe-kanban-remote:latest on a daily 07:00 cron. The
mirror still contains upstream's product sunset, which replaced the kanban
board with an export-only page — so the next scheduled run would have
republished a sunset image over :latest. bob is pinned to an immutable tag
and would not have picked it up, but the tag would have been wrong for
anything that did.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182wzZE8DguMPWhxD21gfP2

2026-07-21 15:54:54 +03:00

.gitea/workflows

vibe-kanban-remote: move the build to lair/vibe-kanban

2026-07-21 15:54:54 +03:00

images/hermes

vibe-kanban-remote: move the build to lair/vibe-kanban

2026-07-21 15:54:54 +03:00

.gitignore

Add lair/containers image-build repo; hermes as first image

2026-06-23 12:17:10 +03:00

readme.md

feat(vibe-kanban-remote): build the self-hosted remote-server image

2026-07-20 18:18:43 +03:00

readme.md

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-arg with 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 a Containerfile (or build from an upstream context) + build.sh + readme.md.
Add a job to .gitea/workflows/images.yml that logs in, builds git.lair.cafe/lair/<name>:latest, and pushes.
Consumers pull git.lair.cafe/lair/<name>:latest with AutoUpdate=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.