ci: unify Bazel cache namespaces and fix warm restore fallback (#5651)

[Devansh-567]

Description

This PR addresses an issue where the build_indirect CI job was unable to leverage the Bazel action cache populated by the preceding build_direct job. By unifying the cache key namespace and introducing a structured fallback restore chain, this change eliminates redundant compilation work and significantly reduces CI runtimes for indirect builds.

The Problem

Previously, the two Bazel jobs in ci-bazel.yml isolated their cache targets into entirely separate key spaces:

• build_direct - bazel-direct-{hash}-{run_id}
• build_indirect - bazel-indirect-{hash}-{run_id}

Because Bazel's action cache is content-addressed per compilation unit rather than per job, isolating these keys meant that build_indirect always started with a cold cache, even when build_direct had already compiled identical targets for the exact same commit.

How I Found It

While analyzing workflow execution metrics in ci-bazel.yml, I observed that build_indirect frequently spent significant time recompiling expensive targets (for example, files such as //lib/foo.cc) that had already been built successfully by build_direct.

Reviewing the cache configuration revealed that the complete separation of cache namespaces prevented GitHub Actions from reusing previously generated cache entries. As a result, cache lookups consistently missed, forcing unnecessary recompilation.

Additionally, a review of the cache save and cleanup flow confirmed that the existing logic could be simplified safely once cross-job cache sharing was enabled.

The Solution

Shared Cache Namespace

Both jobs now use a common cache prefix based on:

${{ runner.os }}-bazel-shared-${{ hashFiles(...) }}

This allows cache artifacts generated by one Bazel job to be reused by the other when the underlying inputs are identical.

Cross-Job Warm Restore Fallback

build_indirect now uses an ordered restore chain that:

1. Attempts to restore an exact cache match for the current job.
2. Falls back to a cache generated by build_direct for the same commit signature.
3. Falls back to broader shared prefix matches when no exact match exists.

This ensures maximum cache reuse while still preserving deterministic behavior.

Immutable Cache Writes

Cache save keys now append:

• -direct / -indirect
• ${{ github.run_id }}

This guarantees unique, non-colliding cache writes while respecting the immutable nature of GitHub Actions caches.

Related Issue

Fixes #5651

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• CI/CD / Optimization (improvements to build speeds and workflow configurations)

Verification Checklist

• Validated locally that the updated YAML matches formatting baselines (git diff --check passes cleanly).
• Verified that restore-key precedence behaves as intended and targets the expected cache hierarchy.

[jafingerhut]

@chreekat Are you familiar enough with Bazel to review this?

Either way, it would be good to get Bazel users at Google to take a look. @fruffy I recall you using some kind of alias that one can "at ping" to notify people interested in Bazel, I think?

[chreekat]

This is not a bazel change per se, but a GitHub workflow change.

I think the PR description is a little confused, but the change seems ok. IIUC, the two jobs don't need to be completely independent -- they are just testing different ways of building p4c with bazel. The two ways can use the same bazel cache without breaking anything. So the GH cache (which holds the bazel cache as a payload) can be shared.

I'll let someone closer to the action confirm my understanding -- but if no such person shows up, I say ship it.

@Devansh-567 does my summary look good to you?

[fruffy]

@chreekat Are you familiar enough with Bazel to review this?

Either way, it would be good to get Bazel users at Google to take a look. @fruffy I recall you using some kind of alias that one can "at ping" to notify people interested in Bazel, I think?

@p4lang/google-p4-infra

[Devansh-567]

This is not a bazel change per se, but a GitHub workflow change.

I think the PR description is a little confused, but the change seems ok. IIUC, the two jobs don't need to be completely independent -- they are just testing different ways of building p4c with bazel. The two ways can use the same bazel cache without breaking anything. So the GH cache (which holds the bazel cache as a payload) can be shared.

I'll let someone closer to the action confirm my understanding -- but if no such person shows up, I say ship it.

@Devansh-567 does my summary look good to you?

@chreekat Yes, your summary is spot on!

Even though the two jobs test different ways of building p4c with bazel, the underlying C++ compilation units remain largely identical for the same commit.

By unifying the namespace prefix to bazel-shared- and updating the restore-keys fallback chain, build_indirect can now explicitly reuse the cache payload generated by build_direct. This safely eliminates the redundant compilation of shared targets and significantly optimizes our overall CI runtime without breaking isolation.