fix(ci): run on a label only the Crafter.Build runner carries #38
Merged
jorijnvdgraaf
merged 1 commit from 2026-10-31 00:26:49 +00:00
claude/ci-runner-label into master 2026-10-31
fix(ci): run on a label only the Crafter.Build runner carries
Master's last two runs (#368 and #370) failed in the Build step with The state dir (/root/.cache/flatpak-builder) is not on the same filesystem as the target dir (/workspace/Catcrafts/Crafter.Build) while #369, the 2.2.0 tag run on the same commit with the same flatpak-builder, passed. The difference was the runner. Since 14 October the Hetzner box has a second privileged runner, cx33-org-flatpak, which serves every Catcrafts repository under the label `flatpak` so their package jobs can run crafter-build as a Flatpak. It mounts no host volumes, deliberately, since any repository in the organisation can send it jobs. Whenever it was idle first it took this job too, logged our four volumes as "not a valid volume, will be ignored", and left the flatpak-builder state on the container's overlay while the workspace sat on a Docker volume. Even past that check it would have had no build cache, no web root and no signing key. The org runner's label is right for the jobs it was made for, and giving it our volumes would hand the signing key to every repository in the organisation. So the job asks for a label only its own runner carries: `crafter-flatpak`, after the volumes and key directory that runner alone allows. The runner on the host is relabelled to match (/etc/forgejo-runner/config-flatpak.yaml, previous copy kept as config-flatpak.yaml.bak-2026-10-31-label), so until this reaches master a push there with the old `runs-on: flatpak` goes only to the org runner and fails the same way. AGENTS.md now says the label must stay unique and quotes the error a job on the wrong runner stops with, so the next collision is found from the log. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>