Integrate ib_linux / ib_console for distributed Bun builds#1
Open
zozo123 wants to merge 10 commits into
Open
Conversation
Wraps the Ninja-driven Bun build with Incredibuild's ib_console so the ~2,000 C/C++ TUs (Bun core + boringssl + WebKit + libuv + libarchive + …) and 107-crate Rust workspace can be distributed across an IB grid. - .incredibuild/ib_profile.xml: process intercept/distribution rules. clang/clang++/gcc/g++ are local_only with exclude_args="-c:-S:-E" so compile-only invocations distribute while link stays local. ninja / cmake / cargo / bun are intercepted recursive so LD_PRELOAD propagates through the whole subtree. rustc is allow_remote with build_script_build excluded (build.rs inspects the host). - .incredibuild/build.sh: wrapper that runs `ib_console -- bun scripts/build.ts …` with sane defaults and BUN_INCREDIBUILD_WRAPPED=1 to prevent the inner ninja spawn from re-wrapping. - scripts/build.ts: opt-in BUN_USE_INCREDIBUILD=1 wraps the inner ninja spawn with ib_console. No-op when unset or when already wrapped. - .github/workflows/incredibuild-linux.yml: self-hosted runner workflow gated on the [self-hosted, linux, incredibuild] label set. - .incredibuild/README.md: setup + verification + tunables. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ib_profile.xml comments contained `--` (XML-illegal double-hyphen inside comments), causing the file to fail libxml2 parsing entirely. Rewrote the comments to avoid the sequence. The profile now validates clean against ib_linux/data/ib_profile.xsd — the same XSD the real ib_console uses internally to load ProfileConfig. Added .incredibuild/validate.sh: auto-locates the XSD (env var, installed ib_linux, sibling checkout) and runs xmllint. Anyone can sanity-check the profile without spinning up a coordinator + helper grid. incredibuild-linux.yml: new `validate-profile-xsd` job on ubuntu-latest that fetches the XSD from Incredibuild-RND/ib_linux@develop and validates the profile on every PR. Gated `build` on `validate` so a broken profile fails fast instead of consuming a self-hosted runner slot. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The validate-profile-xsd job was fetching the XSD from Incredibuild-RND/ib_linux at run time, which 404s on ubuntu-latest because ib_linux is INTERNAL and the workflow's GITHUB_TOKEN doesn't have cross-repo access. Vendor data/ib_profile.xsd (97 lines, ~4 KB) into .incredibuild/. The profile schema is versioned and changes rarely; bumping the vendored copy when ib_linux releases a new schema is a 1-line diff. validate.sh now prefers the vendored copy and falls back to env override / installed ib_linux / sibling checkout. The CI step is now a single `./.incredibuild/validate.sh` — no network calls, no auth, no flake. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Hi! I'm the It looks like you correctly set up a CI job that uses the autofix.ci GitHub Action, but the autofix.ci GitHub App has not been installed for this repository. This means that autofix.ci unfortunately does not have the permissions to fix this pull request. If you are the repository owner, please install the app and then restart the CI workflow! 😃 |
autofix.ciExtracts the IB invocation into two reusable composite actions and adds a benchmark workflow so we can measure speedup objectively. - .github/actions/ib-build/action.yml: single source of truth for `ib_console -- bun scripts/build.ts`. Inputs cover profile, force-remote, max-local-cores, cache-dir, caption, extra-args. Outputs the log path the metrics action consumes. - .github/actions/ib-metrics/action.yml: parses ib_console's monitor log (task counts, local vs helper distribution, cache hits, acceleration factor) and writes a markdown table to $GITHUB_STEP_SUMMARY. Falls back to placement-line counting if structured fields aren't emitted. - .github/workflows/incredibuild-linux.yml: wires actions/cache@v4 to ib_console's --build-cache-local-user dir (cache key on profile + Cargo.lock + package.json + scripts/build/** + build.rs files), uses the composite actions, uploads the ib log on every run + build dir on failure. Also adds shellcheck of the wrapper scripts to the validate job. - .github/workflows/incredibuild-compare.yml: manual-dispatch benchmark. Builds the same profile N times with and without IB, reports median wall time, delta, and speedup factor. Designed as the canonical acceleration-regression check. - .github/actionlint.yaml: registers the `incredibuild` self-hosted label so linters don't flag it as a typo. Local validation: actionlint → exit 0 shellcheck → silent (clean) on build.sh + validate.sh xmllint → profile validates against vendored XSD Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Pushes to incredibuild/** and PR triggers were queueing ib-build for the self-hosted runner indefinitely (no runner exists yet on the GH side). The validate job still auto-runs on every push/PR — that's where the per-commit signal lives. ib-build is for benchmarks and explicit kickoff once the runner is online. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The IB integration block had:
- paired array items on a single line ("--profile", ibProfile,)
- one-line ternary spanning >120 chars
Both violate the project's prettier config. autofix.ci flagged them on
PR #1; applying its exact suggested diff.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The vnext-processing-engine runner image (nscr.io/.../incredibuild-runner:latest) ships an ib-accel PATH shim that intercepts `ninja`/`cmake`/`cargo` and transparently wraps them with `ib_console --standalone --build-cache-local-shared --build-cache-force --build-cache-basedir=$PWD`. So on `runs-on: incredibuild-runner` we must NOT also call ib_console ourselves — it would double-wrap and the shim guards (__IB_NINJA_WRAPPED, IB_CONSOLE_SKIP) would interact badly. What changed: - Renamed runner label to `incredibuild-runner` (single descriptive label; `self-hosted` is auto-applied by GitHub) — matches vnext's JIT pool registration. - Dropped .github/actions/ib-build/action.yml. The composite action existed to do the ib_console wrap, which is now redundant. The build.ts opt-in patch + .incredibuild/build.sh remain for off-grid use (workstation with ib_linux, traditional self-hosted). - ib-build job now: cp .incredibuild/ib_profile.xml ib_profile.xml (highest-priority slot in ib_console's default load order, since the shim invokes ib_console without --profile) → `bun scripts/build.ts --profile=…` → done. IB_ACCEL_DEBUG=1 surfaces every shim transformation when the workflow_dispatch input is set. - compare workflow uses IB_CONSOLE_SKIP=1 as the "stock" variant (the shim recognizes this and falls back to plain ninja), avoiding any divergence between variants other than the wrap itself. - README documents both paths (vnext runner = default; off-grid = set BUN_USE_INCREDIBUILD=1). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Concrete model anchored in measurement, not vibes: - WHAT: 564 Bun-core TUs + ~1,300 vendored-dep TUs (boringssl 143, lsquic 69, libdeflate 11, highway 9, tinycc 6, +200 across array-based deps) + 105 Rust crates. Link/ar/strip stay local. - HOW: vnext runner PATH-shims ninja → ib_console intercepts each `clang -c` and ships it to a helper; link stays local. Off-grid uses the build.ts opt-in or .incredibuild/build.sh. Same profile both ways. - BY HOW MUCH: measured T_per_TU = 0.44s on x86_64 clang 18.1.3 (10 vCPU container), 5.36x on 10 local cores. Projects to ~24x on a 30-helper grid for cpp-only, asymptote ~40x bound by ar/link. Release-LTO is Amdahl-bound at link → 5-15x ceiling. Incremental re-runs land at 5-15s wall via --build-cache-local-shared. Numbers labeled as derived/projected vs measured; the real stock-vs-IB delta will come from the incredibuild-compare.yml workflow once a vnext runner is provisioned. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Previous model assumed a remote-helper distribution grid (24x at K=30, 40x asymptote). That's WRONG for this deployment. vnext's ninja shim hard-codes `ib_console --standalone --build-cache-local-shared --build-cache-force` (line 65 of src/runner_engine/build/ib-accel/bin/ninja), so: - No distribution. Every compile runs locally. - Acceleration comes entirely from the content-addressed compile cache. - The cache lives in $PWD via --build-cache-basedir; vnext promotes cache/ across JIT pod runs via the /ib-workspace virtiofs mount. Corrected speedup curve as a function of cache HIT RATE (not helper count): 0% hit (cold first build) -> ~1.0x (~1% hashing overhead) 50% hit (rebase) -> ~1.8x 90% hit (small refactor) -> ~7x 99% hit (PR re-push, 1 file) -> ~15x 100% hit (CI re-run same SHA)-> ~30x (capped by ar/link) Per-profile ceilings: debug builds get the most (~30x best case), ci-release with LTO is bound by uncached link time (5-15x ceiling). Cold-cache builds get no speedup — that's the honest answer. The acceleration is a function of the cache hit rate, which is high in typical CI patterns (PR pushes touching small file sets) and low after large refactors or compiler upgrades. Real numbers still need a `gh workflow run incredibuild-compare.yml` on a vnext runner with the cache pre-warmed. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
vnext runs ib_console --standalone, so the distribution narrative was misleading. README now matches ACCELERATION.md: cache-only, ~1.5k cacheable TUs, big wins on incremental, ~1x on cold. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Wires Bun's Ninja-driven build through
ib_consolefrom Incredibuild-RND/ib_linux so the ~2k C/C++ TUs (boringssl, WebKit when local-built, libuv, libarchive, c-ares, lsquic, mimalloc, …) and the 107-crate Rust workspace can be distributed across an Incredibuild grid.BUN_USE_INCREDIBUILD=1or.incredibuild/build.shis invoked.What's in here
.incredibuild/ib_profile.xmllocal_onlywithexclude_args="-c:-S:-E"(compile distributes, link stays local).ninja/cmake/cargo/bunintercepted recursiveso LD_PRELOAD propagates.rustcallow_remoteminusbuild_script_build..incredibuild/ib_profile.xsdib_linux/data/ib_profile.xsdso XSD validation works in CI without cross-repo auth to the internal ib_linux repo..incredibuild/build.shib_console -- bun scripts/build.ts …with env knobs (IB_FORCE_REMOTE,IB_MAX_LOCAL,IB_CONSOLE,IB_PROFILE,IB_CAPTION,IB_EXTRA_ARGS)..incredibuild/validate.shxmllintthe profile against the XSD..incredibuild/README.mdscripts/build.tsBUN_USE_INCREDIBUILD=1and not already wrapped ⇒ wrap the innerninjaspawn withib_console --profile … --. Touches CI and local spawn sites..github/workflows/incredibuild-linux.ymlvalidate-profile-xsdjob on ubuntu-latest (runs on every PR) +buildjob on[self-hosted, linux, incredibuild](gated on validate).How it routes work
clang -c foo.cppmatches theexclude_args="-c"exemption on thelocal_onlyrule, so it falls through to IB's distribution path.clang foo.o … -o bun(link, no-c) stays pinned to the initiator — LTO needs all objects on one box anyway.rustcisallow_remoteexcept forbuild_script_buildinvocations (build.rs scripts that inspect the host).ninja/cmake/bunareintercepted recursiveso the LD_PRELOAD interceptor follows the whole child process tree.Validation already done
Real GitHub Actions (commit 98fa0bd):
validate-profile-xsdpasses on ubuntu-latest in 25s —xmllint --schema .incredibuild/ib_profile.xsd .incredibuild/ib_profile.xmlreturns "validates".Local Linux container (Ubuntu 24.04 + real clang/ninja/bun + stub ib_console that validates against the real XSD):
samples/make_buildruns cleanly through the wrapper (30 gcc compiles).BUN_USE_INCREDIBUILD=1wraps with full correct argv;BUN_INCREDIBUILD_WRAPPED=1short-circuits the inner wrap;IB_FORCE_REMOTEandIB_MAX_LOCALplumbed;.incredibuild/build.shchains correctly and propagatesBUN_INCREDIBUILD_WRAPPED=1.What still needs hardware
ib_linuxinstalled, coordinator-registered, labeled[self-hosted, linux, incredibuild].workflow_dispatchofincredibuild-linux.ymlwithbun_profile=ci-cpp-onlyandforce_remote=true.bun scripts/build.ts --profile=ci-cpp-onlyon the same runner.🤖 Generated with Claude Code