PJ Reiniger fdc6fd9cb1 [build][bazel] Combine remote setup CI actions (#8893) ...

When the bazel remote cache was switched from buildbuddy to a self
hosted server in #8342, I asked that the buildbuddy hooks be remain so
that I could still use their caching service for local builds.

The downside of this was that my forks builds aren't leveraging
buildbuddy, so if I'm fiddling with something heavy like a wpimath
robotpy thing, my CI builds never update a cache and never are warm when
I push fixups.


This PR combines the `setup-bazel-remote` and `setup-build-buddy`
actions which set up the bazel remote cache. Rather than having two
different version, the correct one will be choosen in the following
order:
1. Use wpi's server with write access if the `bazel_remote` information
is set (This basically would only happen on main branch in
`wpilibsuite/allwpilib` since secrets aren't accessible from builds
originating in forks)
2. Use buildbuddy if the key it is present (This would work for my fork
builds)
3. Fall back to the readonly version of wpi's server


As seen
[here](https://github.com/bzlmodRio/allwpilib/actions/runs/25777428163/job/75712863120#step:7:28)
the build in my fork will run with buildbuddy, and my PR's build here
should fall back to readonly mode.

2026-06-03 20:16:42 -07:00

8.2 KiB

Raw Blame History

View Raw