jenkins: bazelisk, not bazel should be used

[oharboe]

This makes it more obvious that bazelisk is used, which will read in .bazelversion and use the right version.

As it happens, bazel seems to be mapped to bazelisk in this server setup, but I can't know that from reading the local code, so I think using bazelisk is an improvement: it leaves me with fewer questions.

@QuantamHD @hzeller Thoughts?

I came across this as I was trying to figure out why a test works locally and fails in CI

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[hzeller]

Personally, I don't like bazelisk as it is downloading some binary if it feels like. That breaks hermeticity and thus works really badly/not at all on systems that care about that (e.g. nixos). Rather if you want to emphasize a particular bazel version, call it like that, e.g. bazel-7.6.0 build ...

Ideally we should do away with .bazelversion file in the first place if not needed.
I think it it is a poorly implemented feature in bazel as it does not allow for semantic versioning.
Bazelversion only really is needed rarely if there is a particular feature needed or other issue that can't be worked around.

If the build works with bazel 7.x and 8.x, I recommend removing .bazelversion.

[oharboe]

mileage varies with bazel versions, bugs and instabilities are fixed. I dont see the value of OpenROAD "relitigating" fixed bazel problems.

What would be a good way to mandate a minimum version?

[hzeller]

just being able to build with the latest 7.x and 8.x is sufficient, not for every intermediate version.
There might be a way to mandate it, but most people will compile with bazel 7, some with bazel 8 and they all get a good experience.

[oharboe]

There appears to be instabilities fixed in 8.3.1 and .bazelversion communicates that this is the version we test with.

It does not fill me with joy that maintainers and users have to relive fixed bugs.

[oharboe]

Regarding this PR: as long as we are using baselisk, this change minimizes surprises when reading the code: bazelisk is in use.

[hzeller]

Given the circumstances, I think this PR is ok.

[maliberty]

I don't wish to take on the burden to ensure/test on all different versions. I think using the local bazel is more of a break of hermeticity.

[oharboe]

Maybe the bazel version will be specified in MODULE.bazel in the future.

Why is the Bazel version any different from any other dependency, like rules_foo()?

Seems like bazel kicked this can down the road and bazelisk stepped up while the world figures these things out.

[maliberty]

Because bazel is the build tool itself and must be installed in order to even run the build. It is not a dependency of OR.

[gadfort]

@maliberty @vvbandeira is bazelisk installed on jenkins? it looks like none of the bazel builds are building: https://jenkins.openroad.tools/job/OpenROAD-Public/job/master/1552/pipeline-overview/

[oharboe]

@maliberty @vvbandeira is bazelisk installed on jenkins? it looks like none of the bazel builds are building (see the #7725 PR)

My guess would be that bazel is symlinked to bazelisk, but that bazelisk is not in the path.

[maliberty]

What is odd is that the bazel run in the build for this PR used bazel test and not bazelisk. @vvbandeira do you understand why?

[maliberty]

I'm going to revert until we get this fixed

[vvbandeira]

@oharboe @maliberty, see: #7731