makes buf version configurable
#10
Conversation
buf/internal/toolchain.bzl
Outdated
| ctx.download( | ||
| url = "https://github.com/bufbuild/buf/releases/download/{}/{}".format(version, bin), | ||
| sha256 = sum, | ||
| executable = True, | ||
| output = "{}/{}".format(target, bin), | ||
| ) |
There was a problem hiding this comment.
This will download every binary no matter if it ends up being used or not. Can we instead generate http_file rules for each of these?
There was a problem hiding this comment.
How will that work?
Since http_file rules are repository_rules adding them to the generated WORKSPACE won't work as they won't be available within the root workspace.
To generate http_file rules themselves the macro should be able to download the sha256.txt file which may not be possible until bzlmod lands.
There was a problem hiding this comment.
Right, I think this repository rule would do a download for the list of releases and generate generate a bzl file with http_rules that gets loaded in the main repository.
Not sure if that's what rules_go does, but I'm pretty sure there you don't have to download every distribution type of the sdk.
There was a problem hiding this comment.
They try and guess the GOOS and GOARCH in the rule itself and download the appropriate version. The problem with that is for every platform the repo needs to be re triggered, not sure how that affects remote caching
https://github.com/bazelbuild/rules_go/blob/master/go/private/sdk.bzl#L240
There was a problem hiding this comment.
On a single platform, when would the rules be re-triggered? Making users download the cross product of os+cpu architecture does not seem like the right direction, I doubt that other toolchains like a clang/gcc would force this. Can we explore alternatives a bit more?
| sha_list = ctx.read("sha256.txt").splitlines() | ||
| for sha_line in sha_list: | ||
| if sha_line.strip(" ").endswith(".tar.gz"): | ||
| continue | ||
| (sum, _, bin) = sha_line.partition(" ") | ||
| bin = bin.strip(" ") |
There was a problem hiding this comment.
Have we committed to our sha256.txt file format? Given that something is a plain text file, this seems pretty easy to change without knowing that it needs to have an exact format or the bazel rule updating will break.
There was a problem hiding this comment.
I share the concern. We have been consistent so far. Is there any alternative that you have in mind?
I was hoping GitHub's API would have it but no luck there.
There was a problem hiding this comment.
At minimum updating the release instructions and scripts to contain notes/comments that indicate this isn't an arbitrary format txt file, but maybe we should update the releases to contain a shas.json file or similar?
There was a problem hiding this comment.
sha.json will be better if we can get it before we release v1.0.0. That way we can limit the minimum version to be v1.0.0 and only depend on the json file.
I'll take this up on buf. Merging this for now.
| """ | ||
|
|
||
| def _register_toolchains(repo, cmd): | ||
| native.register_toolchains( |
There was a problem hiding this comment.
Here we are registering only one toolchain per tool. It will be backed by the right binary. That is handled by _buf_download_releases
| }, | ||
| ) | ||
|
|
||
| def declare_buf_toolchains(os, cpu, rules_buf_repo_name): |
There was a problem hiding this comment.
Declare the toolchains in the proxy repo and reference the toolchain type in rules_buf
Closes #4
This depends on our GitHub release assets of buf. It defaults to latest version if one is not provided. We download the
sha256.txtof a release and download the releases using those hashes.