From f5deb31370b9369241bebd0f2fcca06cb4060369 Mon Sep 17 00:00:00 2001 From: Thom Lamb Date: Mon, 31 Aug 2026 14:45:11 -0500 Subject: [PATCH] chore(ci): remove the registry spike workflow (#237) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .gitea/workflows/spike-registry.yml | 117 ---------------------------- 1 file changed, 117 deletions(-) delete mode 100644 .gitea/workflows/spike-registry.yml diff --git a/.gitea/workflows/spike-registry.yml b/.gitea/workflows/spike-registry.yml deleted file mode 100644 index 3eeb306..0000000 --- a/.gitea/workflows/spike-registry.yml +++ /dev/null @@ -1,117 +0,0 @@ -name: SPIKE — registry build and push - -# THROWAWAY. Delete this file when #237 is answered, whichever way it goes. -# -# It exists to answer three questions that cannot be answered by reading -# anything in this repository, before a design is built on assumptions about -# them. #233 was designed on an assumption about the build context and broke -# every Portainer deploy; this is the correction to that habit. -# -# 1. Can a job on this runner run `docker build` at all? The other workflows -# use `services:`, which proves the runner can *start* containers, not -# that a job can build images. That needs a Docker socket or buildx. -# 2. Can it push to this Gitea's container registry? The packages API answers -# and lists nothing, so the registry has never been used here and -# "enabled" is unconfirmed. -# 3. How long does the real image take to build here? Not a nice-to-know: -# backend-integration.yml is manual because a job once held this runner -# for 3h12m, and any design that builds on every merge to main lands on -# the same runner. -# -# workflow_dispatch only. It cannot fire on push or pull request, so merging it -# changes nothing until someone presses the button. -on: - workflow_dispatch: - -env: - REGISTRY: gitea.bermudalamb.synology.me - # Gitea's container registry namespaces by owner: //. - IMAGE: gitea.bermudalamb.synology.me/bermudalamb/redefined-designs - -jobs: - spike: - runs-on: ubuntu-latest - # The same reasoning as backend-integration.yml: not a performance budget, - # a stop so that a hang costs minutes rather than hours of a runner that - # everything else queues behind. - timeout-minutes: 25 - - steps: - - name: Checkout - uses: actions/checkout@v4 - - # First, and never failing, so that a failure in any later step is still - # informative rather than just "it did not work". - - name: Question 1 — what can this runner do? - continue-on-error: true - run: | - echo "--- docker client/daemon ---" - docker version || echo "NO DOCKER CLI OR DAEMON" - echo "--- buildx ---" - docker buildx version || echo "NO BUILDX" - echo "--- socket ---" - ls -l /var/run/docker.sock || echo "NO DOCKER SOCKET" - echo "--- disk ---" - df -h / | tail -1 - - # Reported as a boolean, never printed. If this says NO, the login below - # will fail and the fix is to add the secret, not to change the workflow. - - name: Is a token available? - continue-on-error: true - run: | - if [ -n "${{ secrets.GITEA_TOKEN }}" ]; then - echo "GITEA_TOKEN is present" - else - echo "GITEA_TOKEN is EMPTY — add a repo secret with package write scope" - fi - - - name: Question 2a — log in to the registry - run: | - echo "${{ secrets.GITEA_TOKEN }}" \ - | docker login "$REGISTRY" -u "${{ github.actor }}" --password-stdin - - # A trivial image first, deliberately. It separates "can this runner build - # and push anything" from "does our real Dockerfile work here" — if the - # real build fails later, this having passed says the plumbing is fine and - # the problem is ours. - - name: Question 2b — build and push a trivial image - run: | - mkdir -p /tmp/spike - printf 'FROM alpine:3.20\nRUN echo spike > /spike.txt\n' > /tmp/spike/Dockerfile - docker build -t "$IMAGE:spike-trivial" /tmp/spike - docker push "$IMAGE:spike-trivial" - echo "pushed $IMAGE:spike-trivial" - - # The real thing, timed. The tag records the commit so that the pulled - # image can be checked against what was built — which is the whole point - # of the design this spike is testing. - - name: Question 3 — build the real image and time it - run: | - SHORT_SHA="$(git rev-parse --short HEAD)" - echo "building $IMAGE:spike-$SHORT_SHA" - START=$(date +%s) - docker build -t "$IMAGE:spike-$SHORT_SHA" . - END=$(date +%s) - echo "REAL BUILD TOOK $((END - START)) SECONDS" - docker push "$IMAGE:spike-$SHORT_SHA" - echo "pushed $IMAGE:spike-$SHORT_SHA" - - # Proves the commit can actually be baked in, which is the reason for the - # whole exercise. In a Gitea Actions checkout .git is present, unlike in - # Portainer's build context — that difference is exactly what #235 was. - - name: Does the built image know its own commit? - continue-on-error: true - run: | - SHORT_SHA="$(git rev-parse --short HEAD)" - echo "git says: $SHORT_SHA" - echo "image says:" - docker run --rm "$IMAGE:spike-$SHORT_SHA" cat dist/buildInfo.json || echo "no stamp" - - - name: What to do next - if: always() - run: | - echo "If the pushes succeeded, try pulling from Portainer:" - echo " 1. Portainer > Registries > Add registry > Custom" - echo " URL: $REGISTRY (username + a token with package read)" - echo " 2. docker pull $IMAGE:spike-trivial" - echo "Then delete this workflow and the spike-* packages. See #237."