Bazel’s philosophy strongly encourages binding to exact, specific versions of all third-party dependencies to help ensure reproducible builds. As Bazel users, we must remember to extend this philosophy to Bazel itself.

When setting up a Bazel-based build system, you should choose a specific version of Bazel and require all developers and the build system to use it. This can be done in a few ways:

1. Use Bazelisk and a .bazelversion file (recommended)
2. Installing a specific version of Bazel as part of your build and developer VM images / docker containers

With the first approach, upgrades to Bazel can then be treated like any other upgrade: submit a pull request to the repo which updates the value in the .bazelversion file and runs the full continuous integration pipeline.

I learnt this lesson the hard way. We originally configured the development docker container to install bazel-latest by running apt install bazel. This worked fine until a new version of bazel was released that was incompatible with the version of rules_docker we were using. To make the matters worse, this problem would only arise when an individual developer decided to rebuild their Docker container, which could happen at any time.