Upgrade to Bazel 9.0.0 with bzlmod and Go 1.25#640
Upgrade to Bazel 9.0.0 with bzlmod and Go 1.25#640philwo wants to merge 5 commits intobazelbuild:masterfrom
Conversation
|
@Wyverald Would you mind reviewing this PR to check whether the changes I made for migrating to bzlmod look good? @ramymedhat Do you think this PR would be fine to merge here, or do we need to make any preparations to not break internal usage of it by reclient? Thanks in advance to both of you 😊 |
I migrated the project to Bazel 9.0, bzlmod, Go 1.25 and latest versions of our dependencies. Hopefully this makes future upgrades much easier. A few target names of go_library rules changed due to the Gazelle upgrade, which I hope is not a problem - if anyone depends on them it should be trivial to update the references when upgrading to the latest version of the SDK. I verified that the project builds successfully on my machine with Bazel and that Gazelle & bzlmod are happy with the state of things: ```bash $ bazel clean --expunge $ bazel run //:gazelle -- fix $ bazel mod tidy $ bazel build //... ``` In addition, building with `go build ./...` and running the tests with `go test ./...` also works fine for me. :) I fixed a few little things that became necessary after the upgrades: - go/pkg/client/client.go had a non-constant format string in call to status.Errorf, fixed by using status.Error instead. - REAPI got a few new methods in the CAS, which caused build failures in the CAS fakes. Fixed by marking those methods as unimplemented. - I updated the .bazelci/presubmit.yml to use Ubuntu 24.04 and Go 1.25.7 and merged all steps using `go` into a single job to reduce unnecessary duplicate downloads and setup time.
philwo
force-pushed
the
philwo-bumpbazel
branch
from
d72fdb4 to
001b660
Compare
|
|
||
| bazel_dep(name = "grpc", version = "1.76.0.bcr.1") | ||
| bazel_dep(name = "rules_proto", version = "7.1.0") | ||
| bazel_dep(name = "protobuf", version = "33.5") |
There was a problem hiding this comment.
general comment: you can avoid a lot of the diffs in this PR by specifying repo_name in bazel_dep. For this one, you can do bazel_dep(name="protobuf", version="33.5", repo_name="com_google_protobuf"), and that would mean you don't need to update any occurrence of @com_google_protobuf//:foo to @protobuf//:foo. Same with rules_go, googleapis, etc. I'll leave it to the actual maintainers of this project to decide what they want to go with.
There was a problem hiding this comment.
Very cool, thanks! I personally would prefer to take the one-time pain of having the larger diff with the renames, but from then on we're using the "correct" original names from the BCR. But if other maintainers feel strongly about this, or it makes something easier for the import into our internal repo, we can also change it.
|
@bentekkie Could you help me out with a review of this one? The Bazel 9.0.0 PR for remote-apis was just merged, so if we get this one in, too, we'd have both repos fully modernized and up to date :) |
2 participants
I migrated the project to Bazel 9.0.0 bzlmod, Go 1.25 and latest versions of our dependencies. Hopefully this makes future upgrades much easier...
A few target names of go_library rules changed due to the Gazelle upgrade, which I hope is not a problem - if anyone depends on them it should be trivial to update the references when upgrading to the latest version of the SDK.
I verified that the project builds successfully on my machine with Bazel and that Gazelle & bzlmod are happy with the state of things:
In addition, building with
go build ./...and running the tests withgo test ./...also works fine for me. :) I fixed a few little things that became necessary after the upgrades:go/pkg/client/client.gohad a non-constant format string in call tostatus.Errorf, fixed by usingstatus.Errorinstead..bazelci/presubmit.ymlto use Ubuntu 24.04 and Go 1.25.7 and merged all steps usinggointo a single job to reduce unnecessary duplicate downloads and setup time.