[build] use RBE to prepare and build the artifacts for releases

[titusfortner]

🔗 Related Issues

Prerequisite for #17586

💥 What does this PR do?

• Speed up releases on CI by building on RBE instead of the GitHub Action runner (~3-9 minute savings on trunk)
• Release-preparation PRs build stamped release targets at the same time as the tests so the release jobs only need to download artifacts (unless they get restamped).

🔧 Implementation Notes

• prepare-release.sh builds release targets on RBE in parallel with ci-build.sh tests
• dotnet:package builds //dotnet:release, the target prepare-release.sh warms, instead of the //dotnet:all wildcard.
• The stamped actions (Java's manifest jar and what packages it, every .NET compile) rebuild at release because the publish jobs build trunk's squash commit, a different SHA from the PR's merge commit.
• rbe is a task argument next to nightly that selects the existing rbe_release config over the release config.
• Rake tasks default to building locally if releasing from local machine
• RBE requires JRuby still
• The nightly runs the same prepare job before its publish jobs, so the nightly's Java timing is the release's and the script is exercised daily.
• Raises the RBE client cap from -j 50 to the cluster's 100 executors to allow a single run to take full use of capacity if needed.
• ci-build.sh currently executes a bazel build run after a bazel test run; this PR skips this build for release-preparation PRs since prepare-release.sh includes it and runs in parallel
• Prepare Release is added to the release ruleset's required checks, since on release-preparation PRs it replaces the release-artifact build that ran inside the required Test job.
• The prepare job shares the RBE cluster with the prep PR's tests which could slow wall-clock time for ci-rbe workflow, except this will be counteracted by the -j value change assuming no other PRs are running simultaneously; regardless less than the 2 minutes saved in publish stage

Expected Release PR Test Timings:

Competing RBE jobs	Today	This PR
Yes	36 min	~35 min
No	36 min	~30 min

Expected Publish Timings:

Manager Flag	Trunk	This PR	Prevent re-stamping*
download (current)	~8 min	~6 min	~5 min
all	~23 min	~6 min	~5 min

*See Additional Considerations.

With --manager=all the publish phase is the only lock phase that changes: ~23 min without this PR and the same ~6 with it, so trunk would be locked ~15 min longer today and no longer with this PR. The pre-release phase may also shrink once the cargo-built manager release jobs go away, which is #17586's work, not this PR's.

🤖 AI assistance

• AI assisted (complete below)
  • Tool(s): Claude Code (Fable 5.1)
  • What was generated: the plan review, the implementation, and this description
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

• The main reason for this change is to support [rust] Allow cross-compilation of selenium-manager on all platforms #17586 since cross-compiling the Selenium Manager binaries in release process would have otherwise added 15 minutes.
• Could avoid rebuilding stamped artifacts by stamping the release label instead of the commit (plus pinning BUILD_HOST/BUILD_USER, which Bazel fills with each runner's hostname). Rebase-merging would not help: GitHub rewrites the SHAs either way.

🔄 Types of changes

• New feature (CI and release tooling; no user-facing change)

[qodo-code-review]

PR Summary by Qodo

Build and warm release publishing targets with RBE

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Builds publishing targets remotely to shorten release and nightly publish jobs.
• Warms stamped release caches during release-preparation and nightly workflows.
• Preserves local release builds while enabling RBE through an explicit task argument.

Diagram

graph TD
  Prep["Release Prep PR"] --> Tests["RBE Tests"]
  Prep --> Warm["Prepare Release"] --> Cache[("RBE Cache")]
  Night["Nightly Trigger"] --> Warm
  Publish["Publish Jobs"] --> Tasks["Release Tasks"] --> Cache
  Tasks --> Registries["Package Registries"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Upload prepared artifacts between jobs

• ➕ Makes artifact reuse explicit and independent of remote-cache retention.
• ➕ Could eliminate rebuilding for targets whose outputs are directly publishable.
• ➖ Requires maintaining artifact lists and paths for every language ecosystem.
• ➖ Stamped outputs can still rebuild when preparation and publishing use different commit SHAs.
• ➖ Adds upload and download overhead plus artifact lifecycle complexity.

2. Enable RBE implicitly in CI release tasks

• ➕ Avoids adding an rbe positional argument to every workflow command.
• ➕ Reduces the chance that a CI publishing job accidentally builds locally.
• ➖ Couples task behavior to environment detection and makes execution less explicit.
• ➖ Risks changing local or non-GitHub release behavior unexpectedly.
• ➖ Is harder to reproduce and debug from a developer machine.

Recommendation: Keep the PR's explicit rbe task argument and shared-cache warming strategy. It reuses existing Bazel configurations, preserves local release defaults, exercises preparation daily through nightly CI, and avoids a complex cross-job artifact contract; artifact handoff is only preferable if remote-cache reuse proves unreliable.

Files changed (11) +71 / -24

Enhancement (5) +17 / -12

dotnet.rakeSupport RBE configuration for .NET releases +3/-2

Support RBE configuration for .NET releases

• Recognizes the 'rbe' release argument and selects 'rbe_release' for both packaging and publishing. Local invocations continue using the standard release configuration.

rake_tasks/dotnet.rake

java.rakeSupport RBE configuration for Java releases +4/-3

Support RBE configuration for Java releases

• Consumes an optional 'rbe' argument and applies the selected configuration to Java builds, packaging, and Maven deployment targets. Existing nightly and local behavior remains intact.

rake_tasks/java.rake

node.rakeSupport RBE configuration for Node releases +2/-1

Support RBE configuration for Node releases

• Adds 'rbe' argument handling and uses the selected release configuration for the JavaScript publish target, including dry runs.

rake_tasks/node.rake

python.rakeSupport RBE configuration for Python releases +2/-1

Support RBE configuration for Python releases

• Selects 'rbe_release' when requested and applies it to nightly or standard Python publishing commands. Local releases still default to 'release'.

rake_tasks/python.rake

ruby.rakeSupport RBE configuration for Ruby gem releases +6/-5

Support RBE configuration for Ruby gem releases

• Passes the selected release configuration into the gem publishing helper. Both nightly and standard WebDriver and DevTools gem targets can now execute through RBE.

rake_tasks/ruby.rake

Other (6) +54 / -12

.bazelrc.remoteAllow RBE builds to use all 100 cluster executors +3/-3

Allow RBE builds to use all 100 cluster executors

• Raises Bazel's remote parallelism limit from 50 to 100 so a single release or CI run can consume the full executor pool. Updates the resource-scaling comment accordingly.

.bazelrc.remote

ci-rbe.ymlWarm release targets alongside release-preparation tests +11/-1

Warm release targets alongside release-preparation tests

• Skips the duplicate release-artifact build in the test job for release-preparation branches. Adds a JRuby-based preparation job that builds stamped release targets on RBE for trunk and release-preparation runs.

.github/workflows/ci-rbe.yml

nightly.ymlPrepare the RBE cache before nightly publishing +15/-3

Prepare the RBE cache before nightly publishing

• Adds the shared release-preparation job and makes nightly publishing wait for it. Nightly release tasks now request RBE explicitly, use JRuby where required, and include preparation failures in notifications.

.github/workflows/nightly.yml

release.ymlRun release publishing builds through RBE +4/-3

Run release publishing builds through RBE

• Passes the RBE release mode to language publishing tasks and configures JRuby for Ruby releases. Python and nightly Grid builds now use 'rbe_release' directly.

.github/workflows/release.yml

ci-build.shAvoid duplicate release-artifact builds during preparation +4/-2

Avoid duplicate release-artifact builds during preparation

• Makes the post-test release-artifact build conditional on 'SKIP_RELEASE_ARTIFACTS'. Release-preparation workflows can omit it because the parallel preparation job builds the same deliverables.

scripts/github-actions/ci-build.sh

prepare-release.shPrebuild all publishing targets into the RBE cache +17/-0

Prebuild all publishing targets into the RBE cache

• Introduces a strict shell script that builds Java, Python, Ruby, .NET, and JavaScript release targets using RBE CI execution with release stamping. Minimal remote downloads keep the job focused on warming reusable outputs.

scripts/github-actions/prepare-release.sh

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📜 Skill insights (0)

1. Release routing can regress undetected 📘 Rule violation ☼ Reliability

Description

rbe configuration selection was added separately to each language release task without a focused
test verifying that the argument reaches Bazel as --config=rbe_release. If argument parsing or
task wiring changes, Java, .NET, JavaScript, Python, and Ruby publishing can fall back to the local
release configuration without being caught before a release run.

Code

rake_tasks/java.rake[338]

+  config = args.delete('rbe') ? 'rbe_release' : 'release'

Evidence

PR Compliance ID 5 requires changed behavior to have appropriately scoped coverage. The cited
additions independently introduce the same untested release-configuration branch in all five
language publishing tasks, while the PR adds no corresponding test changes.

AGENTS.md: Add Focused Tests and Prefer Reliable Unit Tests Without Mocks
rake_tasks/java.rake[335-363]
rake_tasks/dotnet.rake[35-55]
rake_tasks/node.rake[74-105]
rake_tasks/python.rake[30-61]
rake_tasks/ruby.rake[75-116]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `rbe` argument controls release configuration across five publishing tasks, but no focused test verifies its parsing or propagation to Bazel.

## Fix Focus Areas
- rake_tasks/java.rake[335-363]
- rake_tasks/dotnet.rake[35-55]
- rake_tasks/node.rake[74-105]
- rake_tasks/python.rake[30-61]
- rake_tasks/ruby.rake[75-116]

## Recommended Fix
Add focused task-level tests that invoke each release task with and without `rbe` and verify that Bazel receives `--config=rbe_release` or `--config=release`, respectively. Keep credential checks and publishing side effects isolated while testing the real argument-selection contract.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: ⚖️ Balanced: This localized build-task change alters release artifact construction and could affect build outputs or release behavior, so it warrants a careful single-pass review.

Tip of the day

💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

Code review by qodo was updated up to the latest commit 0938c52

[qodo-code-review]

Code review by qodo was updated up to the latest commit 21aa8fe