From 91e2b67074740eb8d81bfb9b86d2cfb3092a5e3f Mon Sep 17 00:00:00 2001 From: Vuong Hoang Date: Wed, 2 Sep 2026 08:58:45 -0700 Subject: [PATCH] docs(gitea-runner): commit the capability probe as a re-runnable instrument The README's capability table is a measurement with a date on it, and a runner upgrade or a gitea bump can invalidate it without anything saying so. Committing the workflow that produced it means the next person can re-derive the claims instead of trusting them, which is the same posture the training probes take. Carries the three job shapes plus the traps each one cost to find: job images need a node binary or the first `uses:` fails, the Postgres service needed ~6s and a pg_isready wait, and a run must be polled at /actions/runs because /actions/tasks reports it as empty on 1.26.1. Requested by vastblue-dev as a reference for their first smoke. --- .../capability-probe.yaml.example | 84 +++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 stacks/gitea-runner/capability-probe.yaml.example diff --git a/stacks/gitea-runner/capability-probe.yaml.example b/stacks/gitea-runner/capability-probe.yaml.example new file mode 100644 index 0000000..20003d7 --- /dev/null +++ b/stacks/gitea-runner/capability-probe.yaml.example @@ -0,0 +1,84 @@ +# Runner capability probe — the instrument behind the "What a job on this +# runner can actually do" table in README.md. +# +# Committed so the claims can be RE-DERIVED rather than taken on faith. The +# README's table is a measurement with a date on it; runner upgrades, act +# version bumps and gitea upgrades can all invalidate it silently. Re-run this +# after any of those, or before betting a new repo's CI design on the table. +# +# HOW TO RUN +# 1. Create a throwaway repo (a service account's own namespace is fine — +# the fleet runner is registered instance-wide and picks up any repo). +# 2. Commit this file to .gitea/workflows/probe.yml. Adding the file is the +# trigger; there is no workflow_dispatch here on purpose, and the run-rerun +# API 404s on gitea 1.26. +# 3. Poll /api/v1/repos///actions/runs — NOT /actions/tasks, +# which returned an empty workflow_runs for a run that /runs listed and +# executed (gitea 1.26.1). +# 4. Read logs at /actions/jobs//logs. +# 5. DELETE the repo. It is an instrument, not a fixture. +# +# Last run 2026-09-02 on ana-docker-runner (label pfi-fleet): all three green. + +name: capability-probe +on: [push] + +jobs: + # Does a `uses:` ref resolve from OUR mirrors instead of github.com? + # + # This is the per-workflow half of the github-independence work, and it does + # not need the DEFAULT_ACTIONS_URL=self flip that is parked on act_runner's + # action-fetch auth. A bare `uses: actions/checkout@v4` goes to github at + # step zero; the full URL does not. + mirror-uses: + runs-on: pfi-fleet + # node:20-bookworm, not python:*-slim. JS actions execute as + # `node /var/run/act/actions/.../dist/index.js`, so a job image without a + # node binary fails on its FIRST `uses:` regardless of what the step does. + # This image also carries git, which checkout needs. + container: node:20-bookworm + steps: + - name: checkout from the local gitea mirror, not github + uses: https://gitea.phasefinal.com/actions/checkout@v4 + - run: echo "MIRROR_USES=ok"; git log --oneline -1 + + # Do `services:` containers work, and are they reachable by service name? + # + # The service name is the hostname. Job container is postgres:16-alpine only + # so psql is already present — no apt detour; the steps are plain `run:` so + # this job needs no node. + service-containers: + runs-on: pfi-fleet + container: postgres:16-alpine + services: + probedb: + image: postgres:16-alpine + env: + POSTGRES_PASSWORD: probe + POSTGRES_DB: probe + steps: + - run: | + # WAIT, do not trust startup ordering: the service answered on the + # 4th attempt (~6s) in the 2026-09-02 run. A test suite that connects + # immediately gets a flake that looks like a code bug. + for i in $(seq 1 30); do pg_isready -h probedb -U postgres && break; sleep 2; done + PGPASSWORD=probe psql -h probedb -U postgres -d probe -c 'select version();' + echo "SERVICES=ok" + + # What does a job actually reach on the HOST daemon? + # + # ⚠ Expect this to succeed, and read the output as an exposure report rather + # than a capability list. `container.valid_volumes: []` does not gate it — + # act_runner mounts /var/run/docker.sock itself. On 2026-09-02 this printed + # uid 0 and all 49 containers on ana-docker, gitea included. + docker-reach: + runs-on: pfi-fleet + container: docker:27-cli + steps: + - run: | + echo "--- identity ---"; id + echo "--- socket ---"; ls -la /var/run/docker.sock 2>&1 || echo "NO_SOCKET" + echo "--- host containers visible ---"; docker ps --format '{{.Names}}' 2>&1 | head -8 + echo "--- host container count ---"; docker ps -q 2>/dev/null | wc -l + echo "--- compose plugin ---"; docker compose version 2>&1 | head -2 + echo "REACH_PROBE=done"