CI test. Please ignore

[Yannic]

This will trigger a build to validate some changes we (EngFlow) made to the RBE backend. Not for merging

[CLAassistant]

All committers have signed the CLA.

[qodo-code-review]

PR Summary by Qodo

Bazel: force remote cache invalidation via action/test env and compiler defines

⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Add a global cache-busting knob to Bazel build/test invocations.
• Force remote cache misses by injecting env vars and compile defines.
• Target RBE/remote caching behavior without touching build rules.

Diagram

graph TD
  CI["CI / Developer"] --> Bazel["Bazel build/test"] --> RBE["RBE execution"] --> Cache[("Remote cache")]
  Rc[".bazelrc"] --> Bazel

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Scope cache-busting to a named Bazel config (e.g., build:ci_nocache)

• ➕ Avoids permanently disabling remote cache for all local and CI builds
• ➕ Makes intent explicit and easier to toggle per workflow
• ➖ Requires updating CI invocation(s) to use the new config
• ➖ Slightly more moving parts than a single global switch

2. Change remote cache namespace/instance name for CI runs

• ➕ Clean separation of CI cache from developer cache
• ➕ Avoids polluting action keys with artificial env/define inputs
• ➖ Requires RBE/cache configuration support for multiple instances/namespaces
• ➖ May be harder to manage across environments

Recommendation: If this is meant as a temporary CI experiment, prefer moving these flags under a dedicated Bazel config (e.g., build:invalidate_remote_cache) and only enabling it in the specific CI job. Keeping global cache-busting in the default build/test options can significantly degrade build performance for all users and workflows.

Files changed (1) +5 / -0

Other (1) +5 / -0

.bazelrcAdd global remote-cache busting env vars and compiler defines +5/-0

Add global remote-cache busting env vars and compiler defines

• Adds INVALIDATE_ALL_REMOTE_CACHE_ENTRIES to Bazel action and test environments, and injects matching -D defines via copt/host_copt. This forces Bazel action keys to change so remote cache entries are not reused (notably impacting RBE/cached builds).

.bazelrc

[qodo-code-review]

Code Review by Qodo

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

Context used

✅ Compliance rules (platform): 11 rules

1. Unscoped Bazel cache busting 🐞 Bug ➹ Performance

Description

The added unconditional .bazelrc options change action environment and compilation flags for all
Bazel builds, which will broadly invalidate existing cache hits and increase build/test latency.
This also impacts RBE runs that rely on the configured remote cache, increasing remote
execution/cache load.

Code

.bazelrc[R153-156]

+build --action_env=INVALIDATE_ALL_REMOTE_CACHE_ENTRIES=yes-absolutely-1
+build --test_env=INVALIDATE_ALL_REMOTE_CACHE_ENTRIES=yes-absolutely-1
+build --copt=-DINVALIDATE_ALL_REMOTE_CACHE_ENTRIES="yes-absolutely-1"
+build --host_copt=-DINVALIDATE_ALL_REMOTE_CACHE_ENTRIES="yes-absolutely-1"

Evidence

The new options are added as unscoped build settings in .bazelrc, so they apply broadly; the
repository’s RBE configuration explicitly enables a remote cache, meaning cache-key changes will
translate to remote cache misses for RBE builds.

.bazelrc[150-156]
.bazelrc.remote[1-6]

Agent prompt

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

### Issue description
`.bazelrc` now unconditionally injects an env var and compiler defines into the build, which changes Bazel action keys and causes widespread cache misses (local and remote). This will slow down CI and local development, and increases load on the configured remote cache.

### Issue Context
The repo uses an RBE config with `--remote_cache` in `.bazelrc.remote`. The new flags are added as plain `build ...` options (not under a dedicated config), so they apply broadly.

### Fix Focus Areas
- .bazelrc[153-156]

### Suggested fix
- Remove these lines entirely, **or**
- Move them under an opt-in config (e.g. `build:cache_bust ...`) or a CI-only config (e.g. `build:rbe-ci ...`) so normal builds keep benefiting from caches.

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

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[qodo-code-review]

1. Unscoped bazel cache busting 🐞 Bug ➹ Performance

The added unconditional .bazelrc options change action environment and compilation flags for all
Bazel builds, which will broadly invalidate existing cache hits and increase build/test latency.
This also impacts RBE runs that rely on the configured remote cache, increasing remote
execution/cache load.

Agent Prompt

### Issue description
`.bazelrc` now unconditionally injects an env var and compiler defines into the build, which changes Bazel action keys and causes widespread cache misses (local and remote). This will slow down CI and local development, and increases load on the configured remote cache.

### Issue Context
The repo uses an RBE config with `--remote_cache` in `.bazelrc.remote`. The new flags are added as plain `build ...` options (not under a dedicated config), so they apply broadly.

### Fix Focus Areas
- .bazelrc[153-156]

### Suggested fix
- Remove these lines entirely, **or**
- Move them under an opt-in config (e.g. `build:cache_bust ...`) or a CI-only config (e.g. `build:rbe-ci ...`) so normal builds keep benefiting from caches.

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

[Yannic]

The failure look like flakes. @titusfortner could you rerun CI please to verify?

[titusfortner]

@Yannic
I can't tell if they are flaky or if something somehow changed since the last time they were cached passing. Investigating.