-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to Bazel 7 #67
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1 @@ | ||
5.1.0 | ||
7.0.0 |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
module( | ||
name = "bazeldnf", | ||
version = "0.6.0", | ||
) | ||
|
||
bazel_dep(name = "bazel_skylib", version = "1.5.0") | ||
bazel_dep(name = "protobuf", version = "21.7", repo_name = "com_google_protobuf") | ||
bazel_dep(name = "rules_go", version = "0.44.0", repo_name = "io_bazel_rules_go") | ||
bazel_dep(name = "gazelle", version = "0.35.0", repo_name = "bazel_gazelle") | ||
|
||
go_deps = use_extension("@bazel_gazelle//:extensions.bzl", "go_deps") | ||
go_deps.from_file(go_mod = "//:go.mod") | ||
|
||
use_repo( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the optimum would be if by default we woulds still just download the recompiled dependencies, so that while we can cleanly pull in the whole go stack, by default we don't have to. Having said that, an initial stab on this which only works with recompile is fine as well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes so rules_go would become a dev dependency, what other rules are doing is having a public directory in our case it would be bazeldnf and in that directory if someone does We would choose to use prebuilt or already built during toolchain registration. Since I started exploring bzlmod for bazeldnf I also wrote/ported some other rules and learned a lot in the process, I need to close this MR and rebuild based on that, we should make lock file support a chance we introduce once we merge bzlmod. |
||
go_deps, | ||
"com_github_bazelbuild_buildtools", | ||
"com_github_crillab_gophersat", | ||
"com_github_onsi_gomega", | ||
"com_github_sassoftware_go_rpmutils", | ||
"com_github_sirupsen_logrus", | ||
"com_github_spf13_cobra", | ||
"io_k8s_sigs_yaml", | ||
"org_golang_x_crypto" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a value which we need to bump for releases to match the release tag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something which we can always set to the tag value in the release script with e.g. buildozer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes so the version is something that gets bumped with a GitHub release and the Bazel central registry (BCR) provided with GitHub workflows to make releasing of new versions trivial, there's a template rule from which every new rule is forking, I need to look into the details and adopt, once we have those hooks a new release for BCR is just a tag in another public GitHub repo