3 Commits

Include renames

Author	SHA1	Message	Date
bermudalamb	c350f0a588	ci: distinguish between missing secrets and variables in QA build ... Separate error messages and guidance for missing secrets versus variables in the QA build configuration check to improve clarity for developers.	2026-08-18 08:20:43 -05:00
bermudalambandClaude Opus 5	711f59c0a1	ci: distinguish why the QA build daemon is unreachable (#25) ... The first dispatch failed at the wait step with nothing to act on. The run logs showed the dind service container was never created — no service startup output at all, and teardown reporting "No such container" for the ID it had recorded — which is what act_runner does when it refuses a privileged container. From the failing step, that is indistinguishable from dockerd simply being slow, so the step now says which one it is: if the service host resolves, the container exists and dockerd is not serving plain TCP on 2375; if it does not resolve, the service never started and the runner needs container.privileged. Also raises the wait from 30s to 90s. The NAS took the full 30s before failing, so the old ceiling was too close to the observed time to distinguish slow from broken. The docker CLI fallback is retained: the runner image has no docker binary, and the static install worked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 08:12:11 -05:00
bermudalambandClaude Opus 5	2a20c0e05b	ci: manual workflow to build and publish the QA image (#25) ... Adds a workflow_dispatch job that builds a chosen ref, pushes it to the Gitea container registry as :qa plus a commit-sha tag, and emails when it is ready. It deliberately does not restart the QA stack — redeploying stays a human action in Portainer. The build runs against a Docker-in-Docker service rather than the NAS's Docker socket. Mounting the host socket into the runner would give every workflow on every branch root-equivalent control of the NAS, production included; pushing to a registry means the image does not need to survive in the build daemon. The QA stack now pulls that image instead of requiring a local build. The previous arrangement meant the image existed only if someone remembered to build it, which produced two confusing failures already: a Docker Hub "pull access denied" when the tag was missing, and a silent stale-image deploy when the build had not been rerun. Two runner capabilities cannot be verified from here — privileged service containers for dind, and a docker CLI in the runner image. The workflow checks both and fails with an explanation rather than a connection refused, and validates all five required secrets and variables up front rather than part-way through a build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 19:10:04 -05:00