fix(ci): use endpoints that exist in Forgejo for wait-time + LAST_DEPLOYED_SHA #529

2026-06-07T11:59:09Z

guettlibot commented

2026-06-07 11:59:09 +00:00

(Migrated from codeberg.org)

Summary

The hourly Deploy workflow's Detect Changed Files job has been failing every hour since run #2165 (issue #527). Two underlying bugs:

Wait-time step: PRs #522/#524 swapped /actions/tasks → /actions/runs in the wait-time curl but did not update the field lookups. Runs expose index_in_repo/created; tasks expose run_number/created_at. The mismatch meant every wait-time step silently logged "unknown (API lookup failed)". Harmless in isolation, but pointed at the deeper issue:
LAST_DEPLOYED_SHA: the change-detection python iterates up to 285 successful runs, calling /actions/runs/{run_id}/jobs for each — Forgejo has no such endpoint, so every call 404s. The urlopen calls were made without a timeout, so when Codeberg gets slow (intermittent 504s), the step can hang past the 5-minute job timeout → failure. This is also true in website.yml.

Changes

Wait-time steps (ci.yml, deploy.yml x5, firebase-tests.yml x2, website.yml): switch to /actions/runs?run_number=$RUN_NUMBER, the swagger-documented filter that returns the single matching run. Read the run's created field. Add --max-time 30 to curl and || true to the assignment so a transient API failure cannot fail the step.
LAST_DEPLOYED_SHA (deploy.yml, website.yml): query /actions/tasks?status=success&limit=100 once and filter client-side for the relevant job (Build & Deploy to Play Store / Build & Update Website) under the matching workflow_id. Task records already expose head_sha, so the broken per-run jobs lookup goes away entirely. Pass timeout=60 to urlopen so the step cannot hang.

Verification

Tested both API queries against the live Codeberg API:

runs?run_number=2173 → returns a single run with the expected created timestamp.
tasks?status=success&limit=100 filtered for deploy.yml + Build & Deploy to Play Store → resolves to the most recent successful Play Store deploy SHA (today's HEAD, so the next hourly tick will correctly skip with "already deployed").
Same filter for website.yml + Build & Update Website → resolves to the last successful website deploy SHA.

YAML syntax validated for all four workflow files.

Closes #527

🤖 Generated with Claude Code

## Summary The hourly **Deploy** workflow's `Detect Changed Files` job has been failing every hour since run #2165 (issue #527). Two underlying bugs: 1. **Wait-time step:** PRs #522/#524 swapped `/actions/tasks` → `/actions/runs` in the wait-time curl but did not update the field lookups. Runs expose `index_in_repo`/`created`; tasks expose `run_number`/`created_at`. The mismatch meant every wait-time step silently logged "unknown (API lookup failed)". Harmless in isolation, but pointed at the deeper issue: 2. **LAST_DEPLOYED_SHA:** the change-detection python iterates up to 285 successful runs, calling `/actions/runs/{run_id}/jobs` for each — Forgejo has **no such endpoint**, so every call 404s. The `urlopen` calls were made without a timeout, so when Codeberg gets slow (intermittent 504s), the step can hang past the 5-minute job timeout → failure. This is also true in `website.yml`. ## Changes - **Wait-time steps** (ci.yml, deploy.yml x5, firebase-tests.yml x2, website.yml): switch to `/actions/runs?run_number=$RUN_NUMBER`, the swagger-documented filter that returns the single matching run. Read the run's `created` field. Add `--max-time 30` to curl and `|| true` to the assignment so a transient API failure cannot fail the step. - **LAST_DEPLOYED_SHA** (deploy.yml, website.yml): query `/actions/tasks?status=success&limit=100` once and filter client-side for the relevant job (`Build & Deploy to Play Store` / `Build & Update Website`) under the matching `workflow_id`. Task records already expose `head_sha`, so the broken per-run jobs lookup goes away entirely. Pass `timeout=60` to `urlopen` so the step cannot hang. ## Verification Tested both API queries against the live Codeberg API: - `runs?run_number=2173` → returns a single run with the expected `created` timestamp. - `tasks?status=success&limit=100` filtered for `deploy.yml` + `Build & Deploy to Play Store` → resolves to the most recent successful Play Store deploy SHA (today's HEAD, so the next hourly tick will correctly skip with "already deployed"). - Same filter for `website.yml` + `Build & Update Website` → resolves to the last successful website deploy SHA. YAML syntax validated for all four workflow files. Closes #527 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: guettli/sharedinbox#529