[build] use Bazel repo contents cache instead of bazel-contrib external-cache

[titusfortner]

🔗 Related Issues

#17598 reduced cache sizes sufficient to switch strategies

Expected repository-cache size based on fork execution

OS	Cache Size
Linux	3.6 GiB
Darwin	2.0 GiB
Windows	2.4 GiB
Total	~8.1 GiB

💥 What does this PR do?

• Switches the GitHub Actions cache layer from bazel-contrib/setup-bazel's external-cache to Bazel's built-in --repo_contents_cache
• Remove the no-cache backup step, the failure mode is that the repository cache didn't extract properly in which case bazel will just regenerate it, will take longer, but continue-on-error is sufficient

🔧 Implementation Notes

• No longer have to maintain an exclusion manifest list
• The repository cache is generated on windows and mac without pinned browsers to ensure they aren't included to increase the cache size. Either Selenium Manager or Pinned browsers will still need to download something for tests to pass.

🤖 AI assistance

• AI assisted (complete below)
  • Tool(s): Claude Code
  • What was generated:
  • I reviewed all AI output and can explain the change

🔄 Types of changes

• Cleanup (formatting, renaming)

[qodo-code-review]

Review Summary by Qodo

Switch to Bazel repo_contents_cache, remove external-cache

✨ Enhancement

Walkthroughs

Description

• Switches caching strategy from bazel-contrib external-cache to Bazel's built-in
  repo_contents_cache
• Removes complex exclusion manifest for external cache configuration
• Eliminates fallback cache setup step, simplifies error handling
• Reduces total cache size from ~9.5 GiB to ~8.1 GiB across platforms
• Uses --pin_browsers=false for cache population to exclude browser binaries

Diagram

flowchart LR
  A["External Cache<br/>with Manifest"] -->|Remove| B["Repo Contents Cache<br/>Built-in Strategy"]
  C["Fallback Setup<br/>Step"] -->|Remove| B
  D["Complex Exclusion<br/>Rules"] -->|Simplify| E["Pin Browsers Flag"]
  B --> F["Reduced Cache Size<br/>~8.1 GiB"]

Loading

File Changes

1. .bazelrc.remote ⚙️ Configuration changes +0/-1

Remove empty repo_contents_cache configuration

• Removes empty --repo_contents_cache= configuration line from rbe-ci build config
• Cleans up unused cache configuration parameter

.bazelrc.remote

---

2. .github/workflows/bazel.yml ⚙️ Configuration changes +5/-39

Simplify Bazel setup, remove external-cache manifest

• Removes step ID from "Setup Bazel with caching" step and adds explanatory comment about cache
 restore failure handling
• Replaces complex external-cache manifest with 50+ exclusion rules with simple `external-cache:
 false`
• Removes entire "Setup Bazel without caching" fallback step and its conditional logic
• Simplifies "Disk status after cache restore" step by removing conditional warning message

.github/workflows/bazel.yml

---

3. .github/workflows/gh-cache.yml ⚙️ Configuration changes +1/-1

Use pin_browsers flag for cache population

• Replaces --repo_contents_cache= flag with --pin_browsers=false in cache population build
 command
• Ensures browser binaries are not included in generated repository cache

.github/workflows/gh-cache.yml

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0)

1. Repo cache not enabled 🐞 Bug ➹ Performance ⭐ New

Description

CI disables setup-bazel’s external-cache but does not configure Bazel’s --repo_contents_cache
in the workflow invocation, so extracted external repositories are likely no longer persisted across
runs. This undermines the intended cache strategy change and can significantly increase CI time due
to repeated external repo fetch/extract work.

Code

.github/workflows/bazel.yml[R166-170]

Evidence

The workflow now explicitly disables setup-bazel external caching, and the cache-population
workflow no longer passes any --repo_contents_cache flag, leaving no visible configuration in CI
that would enable/persist Bazel’s repo contents cache.

.github/workflows/bazel.yml[159-170]
.github/workflows/gh-cache.yml[35-43]
.bazelrc.remote[59-66]

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 PR turns off `bazel-contrib/setup-bazel` external-cache (`external-cache: false`) and removes the explicit `--repo_contents_cache=` usage in the cache-population workflow, but does not add a replacement configuration that enables and persists Bazel’s built-in repo contents cache.

### Issue Context
`repository-cache: true` typically only covers the download cache (archives), not necessarily the extracted repository contents cache. If `--repo_contents_cache` is not set to a known, persisted location, Bazel will re-extract external repos every run.

### Fix Focus Areas
- .github/workflows/bazel.yml[159-174]
- .github/workflows/gh-cache.yml[35-43]

### What to change
1. Pick a stable path for repo contents cache (e.g. under the same directory that `setup-bazel` caches, or a dedicated directory you cache explicitly via `actions/cache`).
2. Ensure all CI Bazel invocations set `--repo_contents_cache=<that path>` (via `.bazelrc` `common` config, workflow `inputs.run`, or adding it to `bazelrc: common ...`).
3. Ensure the chosen path is included in the cache save/restore mechanism (either `setup-bazel` supports caching it, or add a dedicated `actions/cache` step for it).

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

---

2. Bazel setup failure masked 🐞 Bug ☼ Reliability

Description

.github/workflows/bazel.yml marks bazel-contrib/setup-bazel as continue-on-error, but later
steps still invoke bazel; if setup fails, the job proceeds into harder-to-debug failures (or
missing Bazel entirely). The prior fallback setup step was removed, so there is no longer a
guaranteed successful Bazel installation/configuration when the cached setup fails.

Code

.github/workflows/bazel.yml[R159-165]

Evidence

The workflow explicitly allows the Bazel setup step to fail (continue-on-error: true) but still
runs Bazel commands later in the job; there is no other Bazel installation step, so a setup failure
can surface later as unrelated command failures.

.github/workflows/bazel.yml[159-173]
.github/workflows/bazel.yml[212-223]
.github/workflows/ci-rbe.yml[26-35]
scripts/github-actions/ci-build.sh[15-24]

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 workflow continues even when `bazel-contrib/setup-bazel` fails, but later steps still run Bazel commands. Since the fallback setup path was removed, a cache/restore/setup failure can cascade into confusing downstream failures (e.g., `bazel: command not found`) rather than a clear cache/setup failure.

## Issue Context
This reusable workflow is used by many CI jobs; the Bazel setup step is the only place Bazel is installed/configured in the job.

## Fix Focus Areas
- .github/workflows/bazel.yml[159-177]
- .github/workflows/bazel.yml[212-223]

## Suggested fix
1. Re-add an `id` to the cached setup step (e.g., `id: setup-bazel-cached`).
2. Re-introduce a fallback step that runs `bazel-contrib/setup-bazel` again **without cache restore/save** when the cached setup step fails (or alternatively, keep setup non-`continue-on-error` and make only the cache restore non-fatal if the action supports it).
3. Optionally restore a warning log when the cached setup step fails to preserve observability.

This keeps the intended behavior (build proceeds on cache failures) while ensuring Bazel is actually available for the later `Run Bazel` step.

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

---

Previous review results

Review updated until commit 135c220

Results up to commit b6e4a09

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Bazel setup failure masked 🐞 Bug ☼ Reliability

Description

.github/workflows/bazel.yml marks bazel-contrib/setup-bazel as continue-on-error, but later
steps still invoke bazel; if setup fails, the job proceeds into harder-to-debug failures (or
missing Bazel entirely). The prior fallback setup step was removed, so there is no longer a
guaranteed successful Bazel installation/configuration when the cached setup fails.

Code

.github/workflows/bazel.yml[R159-165]

Evidence

The workflow explicitly allows the Bazel setup step to fail (continue-on-error: true) but still
runs Bazel commands later in the job; there is no other Bazel installation step, so a setup failure
can surface later as unrelated command failures.

.github/workflows/bazel.yml[159-173]
.github/workflows/bazel.yml[212-223]
.github/workflows/ci-rbe.yml[26-35]
scripts/github-actions/ci-build.sh[15-24]

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 workflow continues even when `bazel-contrib/setup-bazel` fails, but later steps still run Bazel commands. Since the fallback setup path was removed, a cache/restore/setup failure can cascade into confusing downstream failures (e.g., `bazel: command not found`) rather than a clear cache/setup failure.

## Issue Context
This reusable workflow is used by many CI jobs; the Bazel setup step is the only place Bazel is installed/configured in the job.

## Fix Focus Areas
- .github/workflows/bazel.yml[159-177]
- .github/workflows/bazel.yml[212-223]

## Suggested fix
1. Re-add an `id` to the cached setup step (e.g., `id: setup-bazel-cached`).
2. Re-introduce a fallback step that runs `bazel-contrib/setup-bazel` again **without cache restore/save** when the cached setup step fails (or alternatively, keep setup non-`continue-on-error` and make only the cache restore non-fatal if the action supports it).
3. Optionally restore a warning log when the cached setup step fails to preserve observability.

This keeps the intended behavior (build proceeds on cache failures) while ensuring Bazel is actually available for the later `Run Bazel` step.

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

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit 135c220