chore(ci): remove the registry spike workflow (#237)
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
This commit is contained in:
@@ -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: <host>/<owner>/<image>.
|
||||
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."
|
||||
Reference in New Issue
Block a user