diff --git a/.github/actions/setup-build-buddy/action.yml b/.github/actions/setup-build-buddy/action.yml index 423398a053..563bfd18b9 100644 --- a/.github/actions/setup-build-buddy/action.yml +++ b/.github/actions/setup-build-buddy/action.yml @@ -8,6 +8,7 @@ inputs: runs: using: "composite" steps: + # Sets up build buddy when no secret is found for the API key. This is most likely because this is triggered from an action from a fork instead of the main allwpilib repo. - name: Setup without key env: API_KEY: ${{ inputs.token }} @@ -17,6 +18,16 @@ runs: echo "No API key secret detected, will setup readonly cache" echo "build:ci --config=build_buddy_readonly" > bazel_auth.rc + # Set up the readonly key only if this build is for a pull request. Push builds happen in the forks repository, + # so the user should set their own buildbuddy api keys up there. Only enabling it for PR's should reduce heavy + # and more random load on the cache. + if [ "${{ github.event_name }}" = "pull_request" ]; then + echo "Assuming this is a pull request from a fork. Setting up the readonly api key" + echo "build:ci --remote_header=x-buildbuddy-api-key=QIOV65PTW1tVal3AJbe7" >> bazel_auth.rc + else + echo "Not setting up readonly key for trigger ${{ github.event_name }} since this is not a pull request, it is most likely a forks push. See the buildbuddy setup guide in README-Bazel.md to set up caching on your fork" + fi + - name: Set with key env: API_KEY: ${{ inputs.token }} diff --git a/README-Bazel.md b/README-Bazel.md index fc4ddf0b30..15767210e7 100644 --- a/README-Bazel.md +++ b/README-Bazel.md @@ -29,3 +29,17 @@ allwpilib uses extensive use of pre-generating files that are later used to buil these pre-generation scripts use some configuration file to create multipile files inside of an output directory. While this process could be accomplished with a `genrule` that would require an explicit listing of every output file, which would be tedious to maintain as well as potentially confusing to people adding new features those libraries. Therefor, we use `@aspect_bazel_lib` and their `write_source_files` feature to generate these directories. In the event that the generation process creates more than a small handful of predictable files, a custom rule is written to generate the directory. + +## Remote Caching +One of the huge benefits of bazel is its remote caching ability. However, due to bazels strict build definitions it is hard to share remote cache artifacts between different computers unless our toolchains are fully hermetic, which means you are unlikely to be able to reuse the cache artifacts published from the `main` branch on your local machine like you might be able to with the `gradle` or `cmake` caches. Luckily the github actions CI machines are generally stable between runs and can reuse cache artifacts, and your local machine should remain stable, so if you set up a free buildbuddy account you can have your forks CI actions be able to use a personalized cache, as well as your local machine. + +For the main `allwpilib` upstream, the cache is only updated on the main branch; pull requests from forks will not be able to modify the cache. However, you can set up your fork to enable its own cache by following the steps below. + +### Setting Up API keys +Follow the [buildbuddy authentication](https://www.buildbuddy.io/docs/guide-auth) guide to create keys. For your local machine, it is recommended that you place the following configuration line in either a `user.bazelrc` or `bazel_auth.rc` file in the repositories root directory. + +``` +build --remote_header= +``` + +To get your forks CI actions using your own buildbuddy cache, follow [GitHub's](https://docs.github.com/en/actions/how-tos/security-for-github-actions/security-guides/using-secrets-in-github-actions) documentation for setting up a repository secret. The secrets key should be `BUILDBUDDY_API_KEY`, and the value should be your buildbuddy API key.