This is blocked on #492 (s390x), since its Docker image doesn't have bazelisk binary (and even if it did, then there are no official Bazel releases for s390x anyway...).

Any argument against closing this PR? It will be forever blocked since we have decided to continue using s390x in CI.

Ignoring s390x for a moment, this PR attempted to address 2 issues:

(1) We're using bazel-contrib/setup-bazel, which installs and configures bazelisk, and not bazel.
(2) We're using .bazelversion to specify Bazel version, but we're calling bazel, and not bazelisk that uses it.

None of those are real problems on GitHub Actions, because the default container images have both tools preinstalled, and bazel is most likely a symlink to bazelisk (otherwise, .bazelversion would be completely ignored, and I don't recall that it is...).

However, this breaks when testing locally using the act tool, since the standard Ubuntu images that are used don't have bazel preinstalled, and nothing in the workflow installs it.

Can we use something like

BAZEL=$(which bazelisk)
BAZEL=${BAZEL:-bazel}

To use bazelisk if it exists, otherwise fallback to bazel?

On linux distros using the official bazel repos or homebrew, bazel can also be installed using a versioned suffix (e.g. apt install bazel-7.7.1) and the correct version of bazel will be invoked.