Follow-up to a2f0a4a, which documented the hazard; this removes it.
resolve-versions read three PUBLIC Gitea repos with `curl -sf -H "$AUTH_HEADER"`.
Gitea rejects an invalid token rather than ignoring it, so the token turned a
read that works anonymously into a hard failure:
no Authorization header 200
empty token (secret unset) 200 <- absent secret was always safe
garbage/revoked token 401 <- stale secret broke the release
A revoked GITEA_BUILD_TOKEN therefore failed resolve-versions via require_sha,
presenting as connectivity or an API fault, on data any anonymous client could
fetch. Hit exactly that failure mode today with an expired PAT.
New gitea_sha() helper tries authed, and on 401/403 retries anonymously with a
loud stderr warning naming the token as the cause. Deliberate choices:
- non-200 after the retry emits nothing and returns 0, so require_sha still
raises the explicit abort — the helper never invents a fallback ref, which is
the property the surrounding code exists to guarantee
- warnings go to stderr, NOT as ::warning:: annotations: the function's stdout
IS the SHA, so an annotation there would be captured into the ref
- the header is still sent first, so a private repo keeps working
Verified by extracting the function from the YAML step body (so the test ran the
committed text, not a copy) and calling it against live Gitea:
valid token -> 0e1369e6b496 (pi-toolkit)
REVOKED token -> warns, retries anon, f60cf9c73205 (mempalace-toolkit)
unset secret -> 98eb07bce60a (pi-extensions)
nonexistent repo -> empty + HTTP 404 warning, so require_sha aborts
Behaviour unchanged on the happy path: all three SHAs are byte-identical to the
ones the v1.8.1 release run resolved with the old curl code. `bash -n` clean on
the extracted step body; YAML re-parsed.
Joakim Persson
ae13c2264e