ci: pin bun off canary on the cloud test lanes (unhang hosted bun install) - #11547
Conversation
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
0xSolace
left a comment
0xSolace
left a comment
There was a problem hiding this comment.
Reviewed — [sol-orch]. Diff is exactly the two roots driving the queue-starved lanes (cloud-setup-test-env default + test.yml BUN_VERSION), comments cite the failure mode (canary hang + lockfileVersion 2 vs --frozen-lockfile) with receipts on #11157. Verified the scope claim: ~15 other workflows still float canary (android/apple/benchmark/app-e2e lanes etc), so this deliberately unblocks only the launch-critical CI path — sensible smallest-change; a follow-up sweep can pin the rest once this proves out. One note for the follow-up: root package.json packageManager is bun@1.4.0-canary.1, so local dev and CI will differ slightly until that's reconciled — fine for the unhang, worth aligning later. Approving; author/maintainer merges.
…stall`) The queue-starved lanes Nubs flagged as the #1 launch bottleneck — Cloud Tests, cloud-e2e, and test.yml's integration/unit/lint/cloud-live-e2e jobs — all sit on the `cloud-setup-test-env` -> `bun install` step on GitHub-HOSTED runners (verified: stuck jobs' runner = `GitHub Actions <id>`, not hetzner-robot; 22 robots online and ~17 idle, so it is not the fleet and not the CP). Floating bun `canary` hangs `bun install` on hosted runners and writes lockfileVersion 2 that breaks --frozen-lockfile — the known #11184/#9454 issue, already pinned to 1.3.14 in ci.yaml but NOT here. Two roots, both pinned to 1.3.14 with the reference comment: - cloud-setup-test-env/action.yml default (Cloud Tests + cloud-e2e call the action with no bun-version override, so the DEFAULT is what runs there). - test.yml env BUN_VERSION (drives its jobs' bun-version input). Scoped to the cloud test lanes on purpose — the wider canary→pin sweep (~86 files) is a separate, lower-urgency change, not landed blind 2 days pre-launch.
b11e529 to
2435f40
Compare
|
Rebased onto Local verification after rebase:
Rebased diff remains scoped to |
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
3 participants
What
Pins bun to
1.3.14(off floatingcanary) on the two roots that drive the queue-starved cloud CI lanes — the #1 launch bottleneck flagged on #11157.Diagnosis (read-only, evidence on #11157)
The stuck lanes — Cloud Tests, cloud-e2e, and
test.yml's integration/unit/lint/cloud-live-e2e jobs — all park oncloud-setup-test-env→bun install. This is not the control plane and not the robot fleet:GitHub Actions <id>(hosted), nothetzner-robot.repos/elizaOS/eliza/actions/runners: 22 hetzner-robots online, ~17 idle — fleet not degraded.Floating
canaryhangsbun installon hosted runners and writes lockfileVersion 2 that breaks--frozen-lockfile— the known #11184 / #9454 issue, already pinned to1.3.14inci.yamlbut never here.Change (2 roots, matching the existing ci.yaml pin + comment)
cloud-setup-test-env/action.ymldefaultcanary→1.3.14. Cloud Tests + cloud-e2e call this action without abun-versionoverride, so the action DEFAULT is what actually runs on those lanes.test.ymlenvBUN_VERSION: canary→1.3.14(drives its jobs'bun-versioninput).Deliberately scoped to the cloud test lanes. The broader
canary → pinsweep across the other ~86 workflow files is a separate, lower-urgency change — not worth landing blind 2 days pre-launch.Claimed on #11157.