Repository navigation
fix(ci): branch-cleanup workflow job has no timeout-minutes — the one runnable job that regressed #61's cap rule #1184
Description
Problem
.github/workflows/branch-cleanup.yml's only job (cleanup) has no timeout-minutes — it is the one runnable job in the repo that regressed the rule closed by #61 ("CI: add timeout-minutes caps to every job in every workflow", closed 2026-10-19).
Evidence (verified this run, main 775632b96a)
grep -L timeout-minutes .github/workflows/*.ymlmatches exactly two files:agents.yml(a thin reusable-workflow caller — caller jobs cannot taketimeout-minutes; the callee owns its caps) andbranch-cleanup.yml(a regularruns-on: ubuntu-latestjob with steps). The other 27 workflow files all carry at least one cap.branch-cleanup.ymlwas added 2026-10-27 in680d6af57c("ci: add stale-branch cleanup workflow") — eight days after CI: add timeout-minutes caps to every job in every workflow #61 closed, so the new workflow never got the cap the repo had just standardized.- The job is exactly the kind that can hang:
actions/checkoutwithfetch-depth: 0, a fullgit fetch --pruneof every branch ref, twogh pr list --limit 1000calls, a per-branchgit log/git merge-baseloop over all remote branches, and up to 50git push origin --deletecalls. With no cap, a stalled fetch/API/push runs to GitHub's 360-minute default instead of failing in minutes. - Precedent values in sibling scheduled housekeeping workflows:
stats.yml15,jules-daily-upstream-sync.yml30,notify-discord.yml10,repo-sweeper.yml90.
Why it matters
A daily scheduled job (cron 17 14 * * *) that can silently burn a 6-hour runner slot on a network stall, delaying its own next runs and hiding a real failure (auth expiry, API stall) behind a timeout nobody chose. #61 already decided this repo's policy; this is the one job that slipped past it.
Acceptance criteria
-
cleanupjob in.github/workflows/branch-cleanup.ymlcarries an explicittimeout-minutes(suggested 30, matchingjules-daily-upstream-sync.yml; justify any other value in the PR). - No other behavior change to the workflow (triggers, permissions, dry-run latch, deletion logic untouched).
- The PR notes that
agents.ymlwas checked and is exempt-by-construction (reusable-workflow caller), so the repo is back to "every runnable job capped" per CI: add timeout-minutes caps to every job in every workflow #61.
Activity
developing-today commentedon Nov 1, 2026
OPENCODE-256
dezren39 commentedon Nov 1, 2026
🤖 Agent note · filed
.github/workflows/*.ymlon main775632b96afor jobs missingtimeout-minutesafter CI: add timeout-minutes caps to every job in every workflow #61 closed that rule on 2026-10-19;branch-cleanup.yml(added 2026-10-27,680d6af57c) is the only runnable job without a cap (agents.ymlis a reusable-workflow caller and cannot take one).creator/1184-branch-cleanup-timeout, addtimeout-minutes: 30to thecleanupjob, PR, merge when verified.jules-daily-upstream-sync.yml(30),stats.yml(15)Merge pull request #1185 from developing-today/creator/1184-branch-cl…
dezren39 commentedon Nov 1, 2026
🤖 Agent note · done
324b75e663a77307d169a0ef473ea50c74a83f14):timeout-minutes: 30on the branch-cleanupcleanupjob. Verified on the laptop before push: YAML re-parsed (jobs.cleanup.timeout-minutes == 30), diff exactly +1 line, no other behavior change.agents.ymlremains exempt by construction as a reusable-workflow caller).