feat(setup-bazel-cache): add Bazel disk/repository cache action

[AlexanderLanin]

Why

Bazel jobs in this org's CI currently rebuild and re-fetch everything from scratch on every run: there's no shared action that caches Bazel's disk cache, repository cache, or Bazelisk downloads across jobs, and no visibility into whether a cache actually helped once one exists. Workflows either accept full rebuild cost every time or hand-roll ad-hoc actions/cache steps per repository, with no consistent key scheme, no generational rollover, and no way to tell whether the cache was hit, partially hit, or useless for a given invocation.

What

Introduces setup-bazel-cache, a self-contained Node action that configures and restores Bazelisk, Bazel disk, and Bazel repository caches (plus optional caching of large extracted external/Bzlmod repositories), and reports cache effectiveness back to the job.

Cache lifecycle

Each cache family (bazelisk/disk/repository/external) gets its own content- or generation-addressed key, restored on every run and published as a new "generation" from the post step once the job's permitted to do so (default: the repository's default branch; configurable via cache-save-branch-patterns). A failed job can still additively save disk/repository caches it successfully restored, so an interrupted build doesn't throw away work already done — external caches are excluded from that path since they're only ever published after a clean success.

Reporting

A temporary bazel/bazelisk launcher is installed on PATH for the duration of the job, transparently adding --execution_log_compact_file, --build_event_json_file, and --profile flags to measured invocations (build/run/test/coverage) without touching the caller's own command line. The post step parses those files to report build-cache and test-result cache-hit rates per invocation in the job log, and — since not everyone wants the extra step-summary table — optionally in the job's step summary too, gated by the new report-cache-step-summary input (default true).

Failure handling

Setup and reporting errors surface as warnings rather than failing the calling workflow; a partially-completed setup skips cache saving rather than leaving inconsistent state behind. This does not change Bazel's own build/test exit codes.

Changes

• setup-bazel-cache/action.yml, README.md, EXPERT.md — action manifest and documentation (quick start, cache-report format, Bazel flag reference)
• src/main.js, src/config.js, src/inputs.js — setup-step orchestration: input validation, cache-mode resolution, branch-save policy
• src/cache.js, src/cache-keys.js, src/cache-size.js — cache restore/save lifecycle, key derivation, and local size measurement, split by concern to keep each file focused
• src/external.js — extracted/Bzlmod external-repository cache handling
• src/invocation.js, src/launcher.js — per-invocation tracking and the transparent bazel/bazelisk launcher wrapper
• src/execution-log.js, src/test-cache.js, src/profile-analysis.js, src/profiling.js — parsers for Bazel's compact execution log, Build Event Protocol test results, and JSON trace profiles
• src/report.js, src/post.js, src/summary.js — post-step reporting (job log, step summary) and setup-step restore summary
• src/git.js, src/workspace.js, src/keys.js — Git history/lock-file comparison, checkout sanity checks, cache-key string encoding
• test/*.test.js — unit coverage per module, plus main.test.js/post-reporting.test.js/failure-handling.test.js exercising the built action end-to-end
• .github/workflows/test-setup-bazel-cache.yml — black-box tests, including a real Bazel build/clean/build cycle that verifies a genuine disk-cache hit is parsed correctly from Bazel's actual execution-log format
• .github/workflows/test-setup-bazel-cache-persistence.yml — exercises real cache persistence (seed, restore, additive save after failure) against the live GitHub Actions cache service
• .github/dependabot.yml, .pre-commit-config.yaml — dependency updates and lint config for the new setup-bazel-cache/ package

[pawelrutkaq]

does this caches external too as seperate caches ? this is important.

[AlexanderLanin]

@pawelrutkaq yes, it does. Currently when the external cache is >500MB. That's a parameter we can tune later.

[lurtz]

I only reviewed the documentation. The code is too much. I put the uses cases I had in mind to the top of the README.md file

[AlexanderLanin]

It seems I cannot get away with updating documentation alone 😢

So I'll push again to the PR branch and cache branch and restart manual testing. It's a full rewrite of the documentation. Sorry about that.

[AlexanderLanin]

Manual testing:

• branch merged = push to main: restore caches, bazel uses caches, report printed, disk cache uploaded
• pull request from fork: restore caches, bazel uses caches, report printed, no caches uploaded
• scheduled run on main: restore caches, bazel uses caches, report printed, caches uploaded as required
• Confirm: A working cache should always be present. Caches should only be deleted after refreshed ones have been created.
• Confirm: bazels caches should not grow without limits. Stale content should be eventually evicted.

[lurtz]

Will this action still be compatible with https://github.com/eclipse-score/cicd-actions/tree/main/warm-bazel-repository-cache ? As far as I understood from your feedback to my review comments, this action will not attempt to solve flaky downloads. Therefore I would expect that we will wire it into the existing cache maintenance logic.

[lurtz]

This only works with stable downloads. https://github.com/eclipse-score/cicd-actions/tree/main/warm-bazel-repository-cache retries the downloads a few times. Until now this worked in inc_someip_gateway reliable.

[AlexanderLanin]

Yeah it's fully compatible. Within this action we could add some bazel flags if that makes sense and leave the proper shell script for re-downloads in warm-bazel-repository-cache.