spike(ci): install a docker CLI so the registry probe can get past login (#237) #244

Closed

bermudalamb wants to merge 2 commits from spike/237-registry-docker-cli into main

pull from: spike/237-registry-docker-cli

merge into: :main

:main

:docs/google-sign-in-plan

Conversation 0 Commits 2 Files Changed 1

+43 -6

2 Commits

Author	SHA1	Message	Date
bermudalamb	30859703d2	spike(ci): authenticate with a package-scoped PAT instead of the Actions token (#237) ... Iteration 2 got as far as the registry and was refused with a 401, not a certificate error, which established that everything except the credential already worked: the docker CLI installs, the daemon is reachable through the mounted socket, the container registry answers on /v2/, and TLS to the Gitea host is trusted from the runner. The token Actions injects automatically is scoped for the repository API and is not accepted by the package registry. This switches to REGISTRY_TOKEN, a personal access token carrying write:package, which is the one thing the workflow could not arrange for itself. Ref #237	2026-08-30 16:32:19 -05:00
bermudalamb	a73f7017f2	spike(ci): install a docker CLI so the registry probe can get past login (#237) ... The first run answered Question 1 with a flat no. The job container has no docker binary, so login died with exit 127 and the three steps that mattered were skipped — no answer on whether the registry accepts a push, and no build time. What it did establish is that /var/run/docker.sock is mounted. The daemon is reachable; only the client is missing. That is a gap a step can close without reconfiguring the runner, so it is worth one more iteration before deciding anything. The static binary rather than apt: one download, no package index to refresh, no repository to add, and only the CLI is wanted since the daemon already exists on the other side of that socket. The architecture is resolved with uname rather than hardcoded. Nothing in this repository has ever confirmed what the NAS is, and assuming x86_64 would waste a whole run on the one machine everything else queues behind — the same class of mistake as assuming Portainer's build context contained .git in #235. This step is deliberately not continue-on-error, unlike the diagnostics above it. If the client cannot be installed there is nothing left to measure, and one clear failure reads better than three skipped steps. Still workflow_dispatch only, still bounded by timeout-minutes, still deleted when #237 is answered. Ref #237	2026-08-30 14:54:53 -05:00