search

rules-proto-grpc / rules_proto_grpc

Bazel rules for building Protobuf and gRPC code and libraries from proto_library targets
https://rules-proto-grpc.com
Apache License 2.0
253 stars 160 forks source link

Tag 1.0.1 package checksum changed #245

Closed johngun3 closed 1 year ago

johngun3 commented 1 year ago

Description

I think is probably just a github system issue I wanted to report it here for visibility: the sha256 of the 1.0.1 tag archive package changed within the last 24 hours.

This url https://github.com/rules-proto-grpc/rules_proto_grpc/archive/refs/tags/1.0.1.tar.gz used to point to a package whose sha256 checksum was 497225bb586e8f587e139c55b0f015e93bdddfd81902985ce24623528dbe31ab but it is now 5fb7f353f181b1b3bb764c7b7f020c1f44400206aafdc9a50ec040f9c8c32a54. This broke some of our bazel builds since the old checksum was explicitly specified as part of a http_archive rule.

aaliddell commented 1 year ago

This is a widespread issue due to a change by GitHub. A lot of other Bazel repos are getting hit too. Follow here for updates:

aaliddell commented 1 year ago

FYI this is getting reverted upstream, so your builds should come back to green soon ✅

valdimarj commented 1 year ago

This might happen again in the future as Github does not guarantee that tarballs under a release archive (urls like archive/refs/tags/$tag) won't change.

The recommended way is to generate the tarball as a part of the release manually/via CI, as per: https://github.com/orgs/community/discussions/22979#discussioncomment-3238584 "So if you need to be absolutely certain that a release artifact won’t change, uploading a release artifact is the way to go, whether it’s a duplication in the common case or not."

aaliddell commented 1 year ago

I can't see GitHub making this change again without a long deprecation period, due to the level of backlash they've seen in the last 24 hours. It'll likely happen accidentally again in the future, but will again be rolled back.

For context of why they cannot realistically ever make this change: for this repo alone I could not publish a static release tar with pinned hashes until every one of our dependencies (of which there are many) have first published a static release tar that I can take the hash of, for which they first have to wait for their dependencies to publish their static release tar, etc etc etc. This process would probably take months and would only take a single core dependency being sluggish to deadlock the entire ecosystem. During this time everyone's builds would be broken, again for maybe months.

When I was considering my next steps yesterday on the chance that it was not not rolled back: the above was becoming a mountain of work (mostly waiting though) just for this repo, so the change would have represented an absurd amount of various maintainers' time just in updating hashes. This is what made the change completely untenable.

However, I agree that publishing a static release tar is prudent now and I shall be looking to add that for upcoming releases but I likely won't be rolling this back into all the old releases.

aaliddell commented 1 year ago

I've pulled the only local action out of this thread into #251; closing this as the checksums are 'stable' again now