improvement(ci): timeouts, docs-only PR skip, fork-isolated caches, Node pin; remove i18n workflow#5714
Conversation
…oped sticky disks, Node pin; drop dead i18n workflow - timeout-minutes on every runnable job (defaults ran hung jobs to the 6-hour cap — the i18n workflow burned three full 6-hour runs in Feb before its schedule was pulled) - paths-ignore on the pull_request trigger: docs content and markdown don't affect the app build or images; push runs stay unfiltered - sticky-disk keys scoped by event name so fork PR runs never share a disk with the push runs that feed production image builds - node-version pinned to 22 (was 'latest', non-deterministic) - delete i18n.yml: schedule already removed after repeated 6-hour hangs, workflow_dispatch-only since, comments stale
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryMedium Risk Overview Pull requests that only touch In test-build, Blacksmith sticky-disk keys are scoped by The Companion, migrations, publish, and other workflows receive matching timeout additions only. Reviewed by Cursor Bugbot for commit 1748c25. Configure here. |
Greptile SummaryThis PR hardens the repository's CI workflows. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (4): Last reviewed commit: "improvement(ci): 45m migrate timeout (co..." | Re-trigger Greptile |
…espaced PR sticky disks - migrate.ts waits up to 30 minutes for the migration advisory lock (LOCK_ACQUIRE_DEADLINE_MS); the 15m job timeout would preempt that designed wait, so the bound is 45m - fork PRs now get their own sticky-disk namespace so an untrusted fork run can't poison the disks that trusted internal-PR runs restore
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 1748c25. Configure here.
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 1748c25. Configure here.
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 1748c25. Configure here.
Follow-up hardening from a full CI audit (all 9 workflows reviewed + run-history analysis).
Changes
1.
timeout-minuteson every runnable job (was: none anywhere). Hung jobs previously ran to GitHub's 6-hour default — not theoretical: the i18n workflow burned three consecutive full 6-hour runs in February before its schedule was pulled (~18h of runner time). Bounds chosen from observed worst cases plus margin: 5m trivial jobs, 10m promote/manifests/release, 15m lint/test/build/migrate/publish, 30m docker matrices (ARM app build runs ~13m).2. Docs-only PRs skip CI.
paths-ignoreon thepull_requesttrigger forapps/docs/content/**and**/*.md. Push runs stay unfiltered — they feed the deploy pipeline. Safe: no ruleset pins required checks.3. Fork-PR cache isolation. Sticky-disk keys are now scoped by
github.event_name, sopull_requestruns (which include fork PRs on this public repo) never write to the disks that push runs — and therefore production image builds — read from. This closes a cache-poisoning path that standard branch protections don't cover, since Blacksmith disks are shared per key across the org. Cost: PR and push caches warm independently (one cold run each after merge).4.
node-version: 22in test-build and docs-embeddings (waslatest— a new Node major could silently change build behavior; publish workflows were already pinned).5. Delete
i18n.yml. Schedule was already removed after the repeated 6-hour hangs; it's beenworkflow_dispatch-only with stale "weekly run" comments since. Restorable from history if auto-translation returns.Audit notes (no action needed)
The audit found the security fundamentals already strong: all actions SHA-pinned, no
pull_request_target, untrusted input handled viaenv:/JS (never shell-interpolated), AWS via OIDC, least-privilege top-level permissions. Deliberately skipped: Vitest sharding (suite too fast to pay for it), merge queue (squash-to-staging flow doesn't need it), Turbo remote cache (sticky disks already provide shared caching).