mirror of
https://github.com/wpilibsuite/allwpilib
synced 2026-06-19 00:41:43 +00:00
fdc6fd9cb1
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.