ci: add timeout-minutes to the release and pages jobs by chethanuk · Pull Request #20 · chethanuk/open-code-review

chethanuk · 2026-07-21T14:23:07Z

Description

3f41551 ("ci: add govulncheck, job timeout, dependabot and preserve debug symbols in dev
builds") introduced timeout-minutes: 15 on the CI test job. This extends that same policy to
the five jobs that still don't have one, so the convention is applied uniformly.

Workflow	Job	Before	After
`ci.yml`	`test`	15	unchanged
`ocr-review.yml`	`review`	30	unchanged
`release.yml`	`build`	—	15
`release.yml`	`release`	—	20
`release.yml`	`npm-publish`	—	15
`deploy-pages.yml`	`build`	—	10
`deploy-pages.yml`	`deploy`	—	15

This matters more than the usual hygiene finding because the runners are self-hosted: a hung
job squats a real machine for GitHub's ~6 hour default rather than a hosted VM you don't own.
npm-publish is the worst case — it can hang mid-publish.

The values are measured, not guessed

Pulled with gh run view <id> --repo alibaba/open-code-review --json jobs, three runs each:

Job	Observed	Chosen	Headroom
`release` `build` (per matrix leg)	0.56 / 0.55 / 0.58 min	15	~25×
`release` `release`	7.08 / 7.06 / 7.03 min	20	2.8× — the tightest
`release` `npm-publish`	3.25 / 3.28 / 3.28 min	15	4.6×
`deploy-pages` `build`	0.93 / 0.95 / 0.96 min	10	~10×
`deploy-pages` `deploy`	0.18 min	15	see below

release is deliberately the loosest at 20: it installs git, does a fetch-depth: 0 clone,
downloads artifacts, computes checksums, uploads 6 files and runs attestation. 2.8× headroom on
a 7-minute job felt right; anything tighter risks a false positive on a slow artifact upload.

`deploy` is 15, not 10, on purpose

actions/deploy-pages@v4's own action.yml declares its internal Pages-polling timeout:

  timeout:
    description: 'Time in milliseconds after which to timeout and cancel the deployment (default: 10 minutes)'
    required: false
    default: '600000'

600000 ms is exactly 10 minutes. A job timeout-minutes: 10 would fire at the same instant, so a
genuinely slow Pages deployment would surface an ambiguous "job cancelled" instead of the
action's own diagnostic error. The job timeout has to exceed the action's internal one, so
deploy gets 15 even though it currently runs in 11 seconds — the one value here not derived
from its own runtime.

Peer evidence

metabase release.yml:34 (per-job timeout-minutes: 10), zed release.yml:50 (60),
signalapp/Signal-Desktop ci.yml:19 (30). Universal in the sample — I didn't find a
comparable release workflow without them.

Verification

Every job in the repo now declares a timeout — asserted rather than eyeballed:

$ python3 - <<'PY'
import yaml, glob
for f in sorted(glob.glob('.github/workflows/*.yml')):
    d = yaml.safe_load(open(f)); jobs = d.get('jobs', {})
    missing = [k for k, v in jobs.items() if 'timeout-minutes' not in v]
    print(f, 'jobs=', len(jobs), 'missing=', missing)
PY
.github/workflows/ci.yml           jobs= 1 missing= []
.github/workflows/deploy-pages.yml jobs= 2 missing= []
.github/workflows/ocr-review.yml   jobs= 1 missing= []
.github/workflows/release.yml      jobs= 3 missing= []

actionlint v1.7.12 — exit 0 on all four workflows
Resolved values re-read from the parsed YAML: release {'build': 15, 'release': 20, 'npm-publish': 15}, deploy-pages {'build': 10, 'deploy': 15}
Re-fetched actions/deploy-pages@v4's action.yml to confirm the 600000 ms claim first-hand

Limitations

No behaviour change unless a job actually exceeds its limit, and none comes close today —
which also means this PR's correctness cannot be positively demonstrated by a CI run. The
evidence is the measurements above.
The chosen values are calibrated against current runtimes on the current self-hosted pool.
If the release job grows substantially, release at 20 is the first one that would need
revisiting — it has the least headroom by design.
I did not test the failure path (deliberately hanging a job to watch the timeout fire).

Type of Change

Bug fix (non-breaking change that fixes an issue)
New feature (non-breaking change that adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Refactoring (no functional changes)
Documentation update
CI / Build / Tooling

How Has This Been Tested?

Measured all five job durations across three real upstream runs each
Schema assertion: every job in all four workflows now has timeout-minutes
actionlint v1.7.12 — exit 0
Independently confirmed actions/deploy-pages@v4's 600000 ms internal timeout, which is
why deploy is 15 rather than 10

Checklist

My code follows the project's coding style
I have performed a self-review of my code
I have added tests that prove my fix is effective — n/a, workflow config
New and existing unit tests pass locally with my changes
I have updated the documentation accordingly (not applicable)
I have signed the CLA

AI assistance: Claude Code helped research and verify this change. I reviewed the full diff
and take responsibility for it.

3f41551 introduced a 15-minute timeout on the CI test job. This extends that same policy to the five jobs that still lack one, so the convention is applied uniformly across all four workflows. Values are set from measured durations over three runs each, not guessed: release build 33-38s -> 15, release 7m03-7m05 -> 20, npm-publish 3m15-3m17 -> 15, pages build 57-58s -> 10, pages deploy 11s -> 15. pages deploy is 15 rather than 10 deliberately: actions/deploy-pages@v4 declares its own internal polling timeout of 600000ms (10 minutes), so a 10-minute job timeout would fire simultaneously and replace the action's diagnostic error with an ambiguous job cancellation. Matters more than usual here because the runners are self-hosted: a hung job squats a real machine for the ~6h default.

coderabbitai · 2026-07-21T14:23:15Z

Warning

Review limit reached

@chethanuk, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 6 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 744032f3-89ec-4cb0-aec9-3854afc5bcac

📥 Commits

Reviewing files that changed from the base of the PR and between c60e886 and 9c2ec28.

📒 Files selected for processing (2)

.github/workflows/deploy-pages.yml
.github/workflows/release.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch ci/job-timeouts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

gemini-code-assist · 2026-07-21T14:23:22Z

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

chethanuk · 2026-07-21T14:58:02Z

@coderabbitai review

coderabbitai · 2026-07-21T14:58:07Z

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ci: add timeout-minutes to the release and pages jobs#20

ci: add timeout-minutes to the release and pages jobs#20
chethanuk wants to merge 1 commit into
mainfrom
ci/job-timeouts

chethanuk commented Jul 21, 2026

Uh oh!

coderabbitai Bot commented Jul 21, 2026 •

edited

Loading

Review limit reached

Uh oh!

gemini-code-assist Bot commented Jul 21, 2026

Uh oh!

chethanuk commented Jul 21, 2026

Uh oh!

coderabbitai Bot commented Jul 21, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

chethanuk commented Jul 21, 2026

Description

The values are measured, not guessed

deploy is 15, not 10, on purpose

Peer evidence

Verification

Limitations

Type of Change

How Has This Been Tested?

Checklist

Uh oh!

coderabbitai Bot commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review limit reached

Uh oh!

gemini-code-assist Bot commented Jul 21, 2026

Uh oh!

chethanuk commented Jul 21, 2026

Uh oh!

coderabbitai Bot commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

`deploy` is 15, not 10, on purpose

coderabbitai Bot commented Jul 21, 2026 •

edited

Loading

coderabbitai Bot commented Jul 21, 2026 •

edited

Loading