ci: bump linux link box to 2xlarge (64 GiB) for full-LTO

[Jarred-Sumner]

Since 02fbd62 (#29618, enable LTO for bun-zig.o), linux aarch64 - build-bun OOMs on r8g.xlarge: lld's full-LTO link now ingests ~1.39 GB of bitcode (794 MB JSC + 347 MB libbun-profile + 247 MB bun-zig.o), peak memory crosses the 31.5 GiB available (no swap) about 18 min in, and the kernel OOM-kills lld — sometimes taking the BuildKite agent with it (exit:-1).

This was already failing on the PR's own CI (build 47390) before merge.

target	instance	bitcode in	result
linux x64-glibc	r7i.xlarge (4c/32G)	1392 MB	pass, 18.98 min
linux aarch64-musl	r8g.xlarge (4c/32G)	1310 MB	pass, 18.15 min
linux aarch64-glibc	r8g.xlarge (4c/32G)	1388 MB	Killed, 18.75 min

x64 has slightly more bitcode and survives, so the tipping factor is LLVM's AArch64 backend holding more state during codegen than X86 — not a clang bug, just expected full-LTO scaling. x64 is one bitcode-adding commit away from the same fate.

Bump both linux link boxes to 2xlarge (8 vCPU / 64 GiB). The extra cores also help lld's parallel LTO codegen phase (the single-threaded merge/opt half won't benefit, so expect ~14–15 min rather than half of 19).

[robobun]

^{Updated 4:46 PM PT - Apr 23rd, 2026}

❌ Your commit 9d436d59 has 2 failures in Build #47592 (All Failures):

• test/js/bun/webview/webview-chrome.test.ts - code 1 on 🍎 14 aarch64
• test/js/bun/webview/webview-chrome.test.ts - code 1 on 🍎 13 aarch64
• test/js/bun/net/socket.test.ts - code 1 on 🪟 2019 x64-baseline
• test/js/bun/net/socket.test.ts - code 1 on 🪟 2019 x64

---

🧪   To try this PR locally:

bunx bun-pr 29650

That installs a local version of the PR into your bun-29650 executable, so you can run:

bun-29650 --bun

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: d8243859-a9c1-41f8-9959-bfab4bd34deb

📥 Commits

Reviewing files that changed from the base of the PR and between bdae27c and 9d436d5.

📒 Files selected for processing (1)

• .buildkite/ci.mjs

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

---

Walkthrough

Updates EC2 instance sizing in the link-bun build step by increasing instance types from xlarge to 2xlarge variants based on architecture, with an added explanatory comment.

Changes

Cohort / File(s)	Summary
Build Configuration .buildkite/ci.mjs	Updates getLinkBunAgent function to increase Linux EC2 instance types from r8g.xlarge/r7i.xlarge to r8g.2xlarge/r7i.2xlarge based on architecture, with added inline comment.

---

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

[claude]

LGTM — straightforward CI instance-size bump to fix LTO link OOMs.

Extended reasoning...

Overview

This PR changes a single line in .buildkite/ci.mjs (getLinkBunAgent), bumping the Linux link-step EC2 instance type from r8g.xlarge/r7i.xlarge (32 GiB) to r8g.2xlarge/r7i.2xlarge (64 GiB), plus an explanatory comment. No logic, control flow, or other agents are touched.

Security risks

None. This is a CI infrastructure config tweak — it only selects a larger AWS instance type for the existing build pipeline. No auth, crypto, permissions, or production code paths are involved.

Level of scrutiny

Low. The change is mechanical and self-contained: a string literal swap for an instance size. The PR description provides clear, well-measured justification (OOM-killed lld during full-LTO link on aarch64 since #29618), and proactively bumps x64 too since it's near the same threshold. The instance family stays the same (r8g/r7i), so AMI/arch compatibility is preserved.

Other factors

No CODEOWNERS entry covers .buildkite/. No prior reviewer comments to address. The bug-hunting system found no issues. The only tradeoff is CI cost, which is an operational decision the author has clearly weighed against the alternative (broken main CI).