bazel: bump bazel-orfs to 05bbceb for cacheable gnumake by openroad-ci · Pull Request #10487 · The-OpenROAD-Project/OpenROAD

openroad-ci · 2026-05-21T23:55:29Z

Summary

Bump BAZEL_ORFS_COMMIT from 78f19f25 (bazel-orfs PR #699 era) to 05bbceb (bazel-orfs PR #717 final).
Picks up upstream's refactor of @gnumake from a Zig + configure bootstrap inside repository_ctx.execute to a plain cc_binary action built with the registered @llvm_toolchain clang.
Removes the last non-cacheable repo-rule execution in our Bazel graph.

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):

INFO: repository @@bazel-orfs++orfs_repositories+gnumake used the following cache hits instead of downloading the corresponding file.
 * Hash 'dd16fb1d...' for https://ftp.gnu.org/gnu/make/make-4.4.1.tar.gz
 * Hash 'c7ae866b...' for https://ziglang.org/download/0.12.0/zig-linux-x86_64-0.12.0.tar.xz
ERROR: external/bazel-orfs+/gnumake.bzl:139:13: An error occurred during the fetch of repository 'bazel-orfs++orfs_repositories+gnumake':
  ...
Error in fail: GNU Make configure failed:
stderr: Timed out; also encountered an error while attempting to retrieve output

Note that the asset-cache --repository_cache downloads succeeded — the failure is in repository_ctx.execute() running ./configure on the extracted source, not in any network fetch. The retry with --keep_going passed because the partial Zig cache from the first attempt was warm.

After the bump, GNU Make builds as a normal cc_binary action. 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)

Commit	Subject	OpenROAD impact
`b10bca4`	private/stages.bzl: SYNTH_NUM_PARTITIONS	private/ — none
`f37bae8`	synth_partition.sh: fix SYNTH_SKIP_KEEP	may shift mock-array synth
`1ac6af9`	synth_partition.sh: parse kept_modules.json	may shift mock-array synth
`5c89e35`	orfs_design: forward user_arguments	additive
`6f3719b`	bazel-orfs internal ORFS/openroad pin bump	none — OpenROAD overrides ORFS via `archive_override`, OpenROAD root
`3e1dc5e`	archive_override support for ORFS	additive
`f1e817f`	bump_test fixture	test-only
`943cae5`	gnumake: drop zig, use cc_binary (PR #717)	the fix
`8e8ade8`	gnumake: hzeller review fold	the fix
`05bbceb`	gnumake: --override_repository docs	docs

Real risk surface = synth_partition.sh tweaks (could shift MockArray_4x4_flat_test gold). Watch that test in CI.

Test plan

Bazel Test stage completes without @@bazel-orfs++orfs_repositories+gnumake fetch timeout.
//test/orfs/mock-array:MockArray_4x4_flat_test and siblings still pass.
Subsequent CI builds show @gnumake//:make as a remote action cache hit.
Full ubuntu:24.04 unit + tcl flow matrix.

gemini-code-assist

Code Review

This pull request updates the BAZEL_ORFS_COMMIT hash in MODULE.bazel and synchronizes the MODULE.bazel.lock file by updating the bzlTransitiveDigest. I have no feedback to provide as there were no review comments.

github-actions · 2026-05-21T23:57:58Z

clang-tidy review says "All clean, LGTM! 👍"

sombraSoft · 2026-05-22T00:41:49Z

@mliberty FIY

sombraSoft · 2026-05-25T17:41:17Z

@oharboe @hzeller — flagging you both since this bumps over your gnumake cc_binary refactor (bazel-orfs#717). hzeller's prediction in the #699 review that zig was too heavy played out: we hit a 300s configure timeout on Jenkins because the repo rule's zig cc step ran on cold cache under load. After this bump GNU Make builds as a normal cc_binary action → cacheable → 540s single-shot vs 1334s with retry on the old pin.

Appreciate any sanity check on the picked-up synth_partition.sh changes against our mock-array tests.

@gnumake

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>

oharboe · 2026-07-08T06:21:08Z

This is a very old PR...?

sombraSoft · 2026-07-08T06:29:04Z

This is a very old PR...?

@oharboe It's old but not stale — master is still pinned to 78f19f25, i.e. before your cc_binary gnumake refactor (bazel-orfs#717). Until this lands we're still exposed to the 300s zig cc configure timeout that motivated it. I just rebased onto latest master; no conflicts, still MERGEABLE.

I scoped this PR deliberately narrow — 78f19f25 → 05bbceb, just enough to pick up the gnumake fix. But bazel-orfs HEAD is now 970ff81, several commits ahead. Would you prefer I bump to a newer pin instead? Happy to move it forward to whatever you'd consider current, as long as we don't drag in changes that shift the mock-array synth gold (the synth_partition.sh tweaks are my only risk surface here). Your call — I can retarget this same PR.

oharboe · 2026-07-08T06:31:10Z

Everything is different now.... in a good way #10812

I'm preparing a bazel-orfs PR, these problems should now go away.

sombraSoft · 2026-07-08T06:35:30Z

Ah, #10812 landing changes the calculus — with hermetic-llvm now registered, the cc_binary gnumake path has a real clang toolchain to build against, which is exactly what bazel-orfs#717 needed. That's better folded into your upcoming bazel-orfs bump than landed as a standalone pin bump you'd just roll past. Sounds like this PR has served its purpose — OK to close it and let your PR carry the fix forward?

oharboe · 2026-07-08T16:00:31Z

Hopefully pr-head/merge will work here now #10841, there's a CI outage on the tidy build.

maliberty · 2026-07-08T16:50:17Z

I don't think the hermetic tool chain includes make, am I wrong?

oharboe · 2026-07-08T16:55:47Z

I don't think the hermetic tool chain includes make, am I wrong?

gnumake for bazel-orfs is compiled with LLVM hermetic toolchain, so caching works better in bazel-orfs across workstations/CI.

maliberty · 2026-07-08T16:59:09Z

It doesn't cache at all as it is a repo rule. In fact I was looking at a CI run where it failed this morning. In bazel 8 we would need to move it to a build action to get caching. In bazel9 there is a new option to cover repo rules (--experimental_remote_repo_contents_cache) but it is new/experimental.

oharboe · 2026-07-08T17:00:23Z

It doesn't cache at all as it is a repo rule. In fact I was looking at a CI run where it failed this morning. In bazel 8 we would need to move it to a build action to get caching. In bazel9 there is a new option to cover repo rules (--experimental_remote_repo_contents_cache) but it is new/experimental.

What doesn't cache? I'm talking about .odb files. I don't care if we have to rebuild gnumake, fast.

oharboe · 2026-07-08T17:02:21Z

I mean, it would be nice if gnumake builds(and all the other various dependencies) cached, but my main concern is that .odb files (ORFS flows in bazel-orfs) cache, that's where the time goes...

maliberty · 2026-07-08T17:02:37Z

Fast isn't the problem - it is flaky as it depends on random servers being up.

maliberty · 2026-07-08T17:03:29Z

I have Claude writing a PR to change this to a build action so it will be cacheable

oharboe · 2026-07-08T17:04:34Z

Fast isn't the problem - it is flaky as it depends on random servers being up.

Right... bazel can add mirrors, I've used it occasionally. Relevant here?

oharboe · 2026-07-08T17:05:15Z

I have Claude writing a PR to change this to a build action so it will be cacheable

Interesting... My head is too full right now :-) too many things in flight.

openroad-ci requested a review from a team as a code owner May 21, 2026 23:55

openroad-ci requested a review from precisionmoon May 21, 2026 23:55

openroad-ci assigned sombraSoft May 21, 2026

github-actions Bot added the size/XS label May 21, 2026

gemini-code-assist Bot reviewed May 21, 2026

View reviewed changes

openroad-ci force-pushed the jl/bump-bazel-orfs-gnumake-cc_binary branch from 22f6fd3 to 7fbabdd Compare July 8, 2026 06:00

sombraSoft closed this Jul 8, 2026

Uh oh!

Conversation

openroad-ci commented May 21, 2026 • edited by sombraSoft Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why now — CI benefits

What else the bump picks up (78f19f25..05bbceb)

Test plan

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

github-actions Bot commented May 21, 2026

Uh oh!

sombraSoft commented May 22, 2026

Uh oh!

sombraSoft commented May 25, 2026

Uh oh!

oharboe commented Jul 8, 2026

Uh oh!

sombraSoft commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oharboe commented Jul 8, 2026

Uh oh!

sombraSoft commented Jul 8, 2026

Uh oh!

oharboe commented Jul 8, 2026

Uh oh!

maliberty commented Jul 8, 2026

Uh oh!

oharboe commented Jul 8, 2026

Uh oh!

maliberty commented Jul 8, 2026

Uh oh!

oharboe commented Jul 8, 2026

Uh oh!

oharboe commented Jul 8, 2026

Uh oh!

maliberty commented Jul 8, 2026

Uh oh!

maliberty commented Jul 8, 2026

Uh oh!

oharboe commented Jul 8, 2026

Uh oh!

oharboe commented Jul 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

openroad-ci commented May 21, 2026 •

edited by sombraSoft

Loading

sombraSoft commented Jul 8, 2026 •

edited

Loading