Bazel installer stopped working after d3f8efc, if project has .bazelversion file

After installing of bazel 2.0.0rc3 I am seeing this:

  $ cd gerrit
  $ cat .bazelversion
  2.0.0rc3
  bazelisk build :gerrit
  019/12/02 21:55:13 Downloading https://releases.bazel.build/2.0.0/rc3/bazel-2.0.0rc3-linux-x86_64...
Starting local Bazel server and connecting to it...
INFO: Invocation ID: 893fd804-3bed-41d5-8b7c-dda793e67520
INFO: Analyzed target //:release (419 packages loaded, 8377 targets configured).
INFO: Found 1 target...
INFO: Deleting stale sandbox base /home/davido/.cache/bazel/_bazel_davido/5c01f4f713b675540b8b424c5c647f63/sandbox
INFO: From Compiling 656 JavaScript files to polygerrit-ui/app/polygerrit_ui_closure_bin.js:
WARNING - Failed to resolve sourcemap at bazel-out/k8-fastbuild/bin/polygerrit-ui/app/custom-style-interface.min.js.map: bazel-out/k8-fastbuild/bin/polygerrit-ui/app/custom-style-interface.min.js.map
  Codes: SOURCEMAP_RESOLVE_FAILED

0 error(s), 1 warning(s)

Target //:release up-to-date:
  bazel-bin/release.war
INFO: Elapsed time: 154.755s, Critical Path: 99.96s
INFO: 435 processes: 3 remote cache hit, 330 linux-sandbox, 8 local, 94 worker.
INFO: Build completed successfully, 457 total actions

As expected, bazel was downloaded by the bazelisk:

  $ ls -all ~/.cache/bazelisk/bin/bazelbuild/bazel-2.0.0rc3-linux-x86_64
-rwxr-xr-x 1 davido users 43780359 Dec  2 21:55 /home/davido/.cache/bazelisk/bin/bazelbuild/bazel-2.0.0rc3-linux-x86_64

Now, if I try to build with bazel directly, bypassing bazelisk, it is failing:

  $ bazel build :gerrit
ERROR: The project you're trying to build requires Bazel 2.0.0rc3 (specified in /home/davido/projects/gerrit2/.bazelversion), but it wasn't found in /home/davido/.bazel/bin.

Bazel binaries for all official releaeses can be downloaded from here:
  https://github.com/bazelbuild/bazel/releases

You can download the required version directly using this command:
  (cd "/home/davido/.bazel/bin" && curl -LO https://releases.bazel.build/2.0.0rc3/release/bazel-2.0.0rc3-linux-x86_64 && chmod +x bazel-2.0.0rc3-linux-x86_64)

Now, I have to fetch bazel twice? It also doesn’t change if I install Bazel locally, I still see the same breakage, even though bazel-2.0.0rc3 was installed:

  $ bash bazel-2.0.0rc3-installer-linux-x86_64.sh --user
  [...]
  Uncompressing.......

Bazel is now installed!

Make sure you have "/home/davido/bin" in your path. You can also activate bash
completion by adding the following line to your :
  source /home/davido/.bazel/bin/bazel-complete.bash

See http://bazel.build/docs/getting-started.html to start a new project!

And bazel still doesn’t work:

  $ bazel version
  Build label: 2.0.0rc3
  $ cd gerrit

  $ bazel build :gerrit
ERROR: The project you're trying to build requires Bazel 2.0.0rc3 (specified in /home/davido/projects/gerrit2/.bazelversion), but it wasn't found in /home/davido/.bazel/bin.

Bazel binaries for all official releaeses can be downloaded from here:
  https://github.com/bazelbuild/bazel/releases

You can download the required version directly using this command:
  (cd "/home/davido/.bazel/bin" && curl -LO https://releases.bazel.build/2.0.0rc3/release/bazel-2.0.0rc3-linux-x86_64 && chmod +x bazel-2.0.0rc3-linux-x86_64)

[Helcaraxan]

We would like to kindly request this issue to be reopened as it does appears to have broken both Bazel and bazelisk at the same time in a significant manner without acceptable workarounds with the 2.0.0 release.

The requirements of CI and an organisation of 100+ engineers mean that the way in which we manage versions for bazel must be fully automated across all three supported platforms in a seamless way. This includes:

• Detecting what version of bazel needs to be used for a given invocation depending on configuration. The version might be different depending on the repository that is being built / tested.
• If the required version is not available on the current machine (local workstation, laptop, CI agent, …) then download it.
• Invoke the required version’s bazel binary with the original command and arguments passed to the top-level bazel invocation.

To achieve this:

• We have historically (3+ years) been using our in-house wrapper tools/bazel script to pin and auto-manage the versions required to build our various repositories. It provides nearly identical features to what bazelisk came to provide at a later point in time.
• In an effort to reduce tech-debt we want to move to simply use bazelisk as an off-the-shelf solution.

While attempting the move to bazelisk we are introducing the required .bazelversion file. While testing this on a Ubuntu workstation that has bazel 2.0.0 installed we found out that the new logic that was added to the wrapper script for bazel’s Debian package makes our attempt at migrating to bazelisk impossible.

The repo under tests currently relies on bazel 1.2.1. When running bazel version with our tools/bazel script stripped to simply invoke bazelisk, we would expect it to invoke bazelisk version which would:

1. Detect the required 1.2.1 version.
2. Detect that it is not currently available in bazelisk’s cache.
3. Download the 1.2.1 binary for Linux.
4. Invoke the freshly downloaded binary with the version command passed to bazelisk at the start.

However, instead, we found that we never even get intobazelisk or even tools/bazel and instead are presented with the already reported error message:

 -> bazel version
ERROR: The project you're trying to build requires Bazel 1.2.1 (specified in /<redacted>/.bazelversion), but it wasn't found in /usr/bin.

You can install the required Bazel version via apt:
  sudo apt update && sudo apt install bazel-1.2.1

If this doesn't work, check Bazel's installation instructions for help:
  https://docs.bazel.build/versions/master/install-ubuntu.html

Although the suggested solution is

to simply do what the (IMHO pretty helpful) error message suggests - install the required Bazel version

this manual actions is clearly not an option given the requirement of automating the entire process, which is the very goal of a tool like bazelisk, as well as Bazel itself.

From reading the code in the wrapper script we have also found that there is no way of deactivating this new logic.

As a result we are now faced with the fact that we cannot at any point in the foreseeable future migrate to bazelisk, even in the theoretical case if this feature was rolled back in a 3.0.0 release. It would still require a .bazelversion file and the mere presence of this file will trigger errors on any Debian-based machine that happens to have bazel 2.0.0 installed, since this feature does its checks before any other wrapper script or user configuration can intervene.

The questions that we have are:

1. What has been the reason to add this .bazelversion logic into the bazel wrapper script? It intermingles the functionality of bazel and bazelisk in an awkward way. The collision on the filename makes it virtually impossible to undo the implications of this change. Releasing a 3.0.0, or 2.0.1 for that matter is not sufficient as people can still have 2.0.0 installed.
2. Why is bazel trying to implement the features that bazelisk already provides in a clean and cross-platform way? The bazelisk tool is already part of the bazelbuild organisation / ecosystem on GitHub and can thus be clearly advertised for people needing the automated version management. All while leaving bazel itself do what it’s good at: building stuff in a fast and reproducible manner.
3. Why has this attempt actually been targeted at only one platform, resulting in bazelisk’s key-feature of automated version management not actually being supported all while actually breaking existing users of bazelisk on that platform?

To be clear: if we had already been using bazelisk before the release of 2.0.0 instead of our in-house script then the release of this “feature” would have actively broken all our Linux-based developers overnight.

[philwo]

Thanks for the input! I’ll go with @Helcaraxan’s plan and will make sure that the fixed wrapper (skip version check if tools/bazel exists) gets into Bazel 2.1.