bazel: bump bazel-orfs to 05bbceb for cacheable gnumake#10487
Open
openroad-ci wants to merge 1 commit into
Open
bazel: bump bazel-orfs to 05bbceb for cacheable gnumake#10487openroad-ci wants to merge 1 commit into
openroad-ci wants to merge 1 commit into
Conversation
Pin moved from 78f19f25 (PR The-OpenROAD-Project#699 era) to 05bbceb (PR The-OpenROAD-Project#717 final). At the old pin, @gnumake's repo rule downloaded the Zig toolchain (~80 MB) and bootstrapped GNU Make 4.4.1 inside repository_ctx.execute via `zig cc -static -target x86_64-linux-musl`, gated by a 300s configure timeout. That setup put GNU Make's build outside Bazel's action graph, so it was not cacheable in the disk/remote action cache and re-ran on every fresh output base. Under load -- 16 parallel jobs on a 16-CPU CI pod with a cold Zig cache -- the configure step occasionally exceeded the 300s timeout. Jenkins build PR-10338-merge The-OpenROAD-Project#21 hit exactly this failure mode in the Bazel Test stage; the retry with --keep_going passed because the partial Zig cache from the first attempt was warm. https://jenkins.openroad.tools/job/OpenROAD-Public/job/PR-10338-merge/21/ PR The-OpenROAD-Project#717 (merged 2026-05-10) refactored the rule on hzeller's review: download GNU Make sources, overlay a vendored config.h and a cc_binary BUILD file, and let the registered @llvm_toolchain clang build make as a normal cc_binary action. No repository_ctx.execute, no Zig, no timeout. Determinism on a fixed host preserved via `-Wl,--build-id=none -Wl,-s`. Net for CI: the gmake binary becomes a cacheable Bazel action -- first build populates the remote action cache, every subsequent fresh pod hits the cache instead of re-running the upstream build. Closes the last non-cacheable repo-rule execution in our Bazel graph (verified: all other repo rules either download prebuilt blobs or push work into actions, e.g. aspect_rules_js npm extracts). Commits between old and new pin that the bump also picks up: b10bca4 private/stages.bzl: register SYNTH_NUM_PARTITIONS f37bae8 synth_partition.sh: fix SYNTH_SKIP_KEEP truthy check 1ac6af9 synth_partition.sh: parse kept_modules.json without greedy sed 5c89e35 orfs_design: forward user_arguments to orfs_flow 6f3719b deps: bump orfs to 523bbbb4, openroad to 07427ed 3e1dc5e feat: support archive_override for ORFS pin f1e817f fix: add missing self-archive fixture to bump_test data 943cae5 gnumake: drop zig bootstrap, build with cc_binary 8e8ade8 gnumake: address hzeller PR The-OpenROAD-Project#717 review 05bbceb gnumake: document --override_repository host-make escape hatch ORFS and OpenROAD pin bumps inside bazel-orfs do not propagate to this repo: OpenROAD is the root module and overrides ORFS via archive_override (ORFS_COMMIT=10a2baea), so bazel-orfs's internal pins are irrelevant. Real risk surface is the synth_partition.sh tweaks (could shift mock-array gold). Watch CI for diffs in MockArray_4x4_flat_test. Signed-off-by: Joao Luis Sombrio <sombrio@sombrasoft.dev>
Contributor
|
clang-tidy review says "All clean, LGTM! 👍" |
Contributor
|
@mliberty FIY |
Contributor
|
@oharboe @hzeller — flagging you both since this bumps over your gnumake Appreciate any sanity check on the picked-up |
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
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
BAZEL_ORFS_COMMITfrom78f19f25(bazel-orfs PR #699 era) to05bbceb(bazel-orfs PR #717 final).@gnumakefrom a Zig + configure bootstrap insiderepository_ctx.executeto a plaincc_binaryaction built with the registered@llvm_toolchainclang.Why now — CI benefits
Old pin built GNU Make inside the repo rule via
zig cc, gated by a 300s configure timeout. Repo-rule work is outside the Bazel action graph, so it never hits the disk/remote action cache and re-runs every fresh output base (i.e. every fresh CI pod).Under load — 16 parallel jobs on the 16-CPU CI pod with a cold Zig cache — the configure step exceeded 300s and failed the build.
We hit this exact failure mode in Jenkins build PR-10338-merge #21 (Bazel Test stage):
Note that the asset-cache
--repository_cachedownloads succeeded — the failure is inrepository_ctx.execute()running./configureon the extracted source, not in any network fetch. The retry with--keep_goingpassed because the partial Zig cache from the first attempt was warm.After the bump, GNU Make builds as a normal
cc_binaryaction. First build populates the remote action cache; every subsequent fresh pod hits the cache instead of re-running the upstream build. Deterministic on a fixed host via-Wl,--build-id=none -Wl,-s.What else the bump picks up (78f19f25..05bbceb)
b10bca4f37bae81ac6af95c89e356f3719barchive_override, OpenROAD root3e1dc5ef1e817f943cae58e8ade805bbcebReal risk surface = synth_partition.sh tweaks (could shift
MockArray_4x4_flat_testgold). Watch that test in CI.Test plan
@@bazel-orfs++orfs_repositories+gnumakefetch timeout.//test/orfs/mock-array:MockArray_4x4_flat_testand siblings still pass.@gnumake//:makeas a remote action cache hit.