chore(ci): remove the registry spike workflow (#237) #249

Merged
bermudalamb merged 1 commits from chore/237-remove-spike-workflow into main 2026-08-31 15:40:35 -05:00
1 Commits
Author SHA1 Message Date
bermudalamb f5deb31370 chore(ci): remove the registry spike workflow (#237)
SonarQube Analysis / sonarqube (pull_request) Successful in 19m39s
Linting / lint (pull_request) Successful in 2m32s
The spike is answered, so the throwaway goes as it always said it would.

What it established. The runner can build images once a docker CLI is installed — the socket was mounted all along and only the client was missing. The container registry works and accepts pushes; it had never been exercised, so that was genuinely unknown. TLS from the runner to the Gitea host is trusted, which also answers the certificate half of the Portainer question. A personal access token with write:package authenticates where the token Actions injects automatically does not. And a full image build and push costs 9m14s on that runner.

What it disproved, which was the point. A CI-built image still reports `commit: "unknown"`. #235 removed `COPY .git` from the Dockerfile to stop the version stamp breaking every Portainer deploy, so it does not matter that an Actions checkout has history — the Dockerfile never copies it. Build location was never the problem, and moving builds to CI would have delivered nothing on its own. #248 carries the actual fix, a build arg, which is a few lines and does not need the registry at all.

Deleting this from main rather than only from the spike branch: it was merged here in #238, before iteration 2 showed that workflow_dispatch fires from a branch and a spike never needed to reach main at all.

Still owed by hand: the spike-trivial and spike-3085970 packages in the registry.

Closes #237
2026-08-31 14:45:11 -05:00