The previous CI fixes (#522, #524) replaced /actions/tasks with
/actions/runs in the wait-time steps but did not update the field
lookups. Runs use index_in_repo + created; tasks use run_number +
created_at. The mismatch meant every wait-time step silently printed
"unknown (API lookup failed)" — harmless on its own, but it signalled
that the surrounding deploy/website change-detection logic was also
calling endpoints that do not exist on Forgejo.
The check-changes job's LAST_DEPLOYED_SHA python iterated up to 285
successful runs, calling /actions/runs/{run_id}/jobs for each — but
Forgejo's API has no such endpoint, so every call 404'd. urllib was
also called with no timeout, so on slow/transient Codeberg responses
the script could hang past the 5-minute job timeout. That is what
caused "Detect Changed Files" to start failing every hour from
run #2165 onward (issue #527).
Switch both classes of API call to endpoints Forgejo actually serves:
- Wait-time steps: query /actions/runs?run_number=\$RUN_NUMBER (the
swagger-documented filter) which returns one run; read the run's
created field. Add --max-time 30 and || true so a transient API
failure cannot fail the step.
- LAST_DEPLOYED_SHA: query /actions/tasks?status=success&limit=100 once
and filter client-side for the specific job (Build & Deploy to Play
Store / Build & Update Website) under the right workflow_id. Task
records expose head_sha, so no second per-run lookup is needed. Pass
timeout=60 to urlopen so the step cannot hang.
Verified against the live Codeberg API: wait-time returns the actual
queued timestamp for run #2173, and LAST_DEPLOYED_SHA resolves to the
expected most-recent successful Play Store / Website deploy SHA.
Closes#527
Thomas Guettler