Repository navigation
fix(ci): test.yml's ci-fix job has no timeout-minutes — per-job gap the file-level check cannot see (#61 rule) #1326
Description
fix(ci): test.yml's ci-fix job has no timeout-minutes — per-job gap the file-level check cannot see (#61 rule)
Evidence
On main 91410958d4, .github/workflows/test.yml:491-503:
ci-fix:
needs: [unit, build, e2e]
if: failure()
permissions:
id-token: write
issues: read
contents: read
runs-on: ubuntu-latest
steps:
- uses: developing-today/code/.github/actions/pm-dispatch-ci-fix@main
continue-on-error: trueThe job has no job-level timeout-minutes, so a hang in the dispatch
action runs to the GitHub Actions default of 360 minutes. The job was added
in a8dfb81801 ("ci: add dispatch agents workflow + ci-fix hook (#979)")
without a cap.
#61 established the rule that every job in every workflow carries a
timeout-minutes cap, and #1184 fixed the same regression in
branch-cleanup.yml. Both were verified at file level — but test.yml does
contain timeout-minutes (on other jobs and on steps), so a file-level
grep -L check passes while this one job is uncapped.
Verified this run by parsing every workflow under .github/workflows/
and checking each runnable job individually: across all 28 workflow files,
ci-fix in test.yml is the only runnable job with no job-level
timeout-minutes (the jobs in agents.yml are reusable-workflow callers,
which cannot take the key). Comparable single-purpose dispatch jobs are
capped: notify-discord.yml's job at 10, branch-cleanup.yml's at 30.
Why it matters
- The job fires exactly when CI is already failing (
if: failure()); a
stuck dispatch would squat a runner for up to 6 hours on top of a red
pipeline, andcontinue-on-error: truedoes not bound how long the step
itself can hang. - The gap is invisible to the verification method used for CI: add timeout-minutes caps to every job in every workflow #61/fix(ci): branch-cleanup workflow job has no timeout-minutes — the one runnable job that regressed #61's cap rule #1184, so
the rule can keep regressing one job at a time inside otherwise-capped
files.
Acceptance criteria
-
ci-fixin.github/workflows/test.ymlhas a job-level
timeout-minutes(10 matches the comparable notify-discord dispatch
job; any small explicit cap is fine). - A per-job scan of all workflows (parse YAML, check every runnable
job) shows no remaining job without a job-level cap. - Nice-to-have: the per-job check is scripted somewhere durable (a
script test or CI step) so the CI: add timeout-minutes caps to every job in every workflow #61 rule is enforced per job, not
per file.
Activity
dezren39 commentedon Nov 1, 2026
🤖 Agent note · self-assigned
timeout-minutes;ci-fixis the only gap)timeout-minutes: 10to theci-fixjob in.github/workflows/test.ymlon branchcreator/1326-ci-fix-timeout, PR, merge when verified.Merge pull request #1327 from developing-today/creator/1326-ci-fix-ti…
dezren39 commentedon Nov 1, 2026
🤖 Agent note · done
timeout-minutes: 10to theci-fixjob in.github/workflows/test.yml. PR fix(ci): cap test.yml ci-fix job at 10 minutes (#1326) #1327 MERGED (merge commit 4c36562), verified on origin/main. Laptop verification pre-merge: diff exactly +1 line, YAML re-parsed, per-job scan of test.yml shows no runnable job without a job-level cap.