The runner executes jobs inside a container that ships no docker client,
so the publish job died on its first command:
/var/run/act/workflow/1: line 3: docker: command not found
act_runner does mount the host's socket into job containers, so only the
client is missing. Both image jobs now fetch the static binary when it is
absent and then check that the socket answers, because "no client" and
"no daemon" are different problems and the log should say which one it
hit. The docker build-test job needed the same treatment — it is skipped
on tags, so it had never reached that command either.
Verified in a container without a docker client: with the socket mounted
the step installs the client and builds the web image; without it the
step fails with the runner-configuration message instead of a confusing
connection error.
Dependencies now ship edition 2024, which Cargo 1.83 refuses to parse:
feature `edition2024` is required
... not stabilized in this version of Cargo (1.83.0)
The pin lived in two places and both had to move, or the daemon image
would have failed the same way the CI job did.
The daemon job assumed a GitHub-hosted runner, where the build user is
unprivileged and sudo exists. Our act runner is a container that runs
as root and ships no sudo, so the step died with "sudo: command not
found" before the toolchain was ever installed — which also blocked the
publish job that waits on it.
Use sudo only when we are not already root, so the step works on both.
docker-compose.panel.yml deploys every service from a published image.
A control panel writes only a compose file and an .env into its project
directory, so the build: stanzas of docker-compose.yml cannot resolve
their context there.
CI pushes api, migrate, web and daemon images to the Gitea container
registry on v* tags. The migrate stage ships as its own image because
the panel compose runs it as a one-shot service before the API starts.
The web port is named HOST_PORT: panels reverse-proxy "the" port of an
installation and need to know which one that is when a stack publishes
more than one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>