GitHub Community
Ensuring identical tarballs from releases #22979
-
|
Hi all, I am studying using the ‘releases’ feature of github to distribute the zip/tar files generated, but I need to be sure that these files are always going to match a precomputed hash. In other words, that these files are generated only once and not on demand, which could lead to changes due to git/zip/tar patches (see this SO question). Now, the URL of release-related tarballs suggest that these are indeed generated only once, when the release is created. On the other hand, tarballs for arbitrary commits (the ones you get from the ‘clone or download’ button) are likely to be generated on demand. I’ve checked the Releases docs without seeing references to this. Anyone knows for sure, or has any further info? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 3 replies
-
|
If you need the downloads for a release to be guaranteed unchanging, your best bet is to upload a binary or set of binaries attached to the release. As for arbitrary commits, we can’t guarantee that the tarballs associated with them will be generated once and never change. I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for confirming the bit about regular commits. We already had discarded the idea of relying on those. I understand from your reply that release zips are also at risk of being regenerated at some point? I didn’t mention in my original post (sorry) but I’m interested in this feature for source distribution only. Uploading binaries, according to the link you posted, seems intended for pre-built binaries, and uploading a zip of sources would be kind of a duplication (although these would certainly be immutable). |
Beta Was this translation helpful? Give feedback.
-
|
What it sounds like you’re asking for is a 100% guarantee that the release tarballs will not change. That’s something that we aren’t going to guarantee. 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. I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
|
The real question is what trigger rebuild of release tarballs on github? I got an interesting report on ansible/ansible-lint#2781 and I want to figure out what is the source of the unexpected checksum changes on archived tags, maybe if there is a way to monitor if any tags are moved? Basically I want to know if the reported changes were caused by repo moves or just archives not being reproducible. |
Beta Was this translation helpful? Give feedback.
-
To update folks with more recent information who stumble across this, apparently that stability is guaranteed now according to bazel-contrib/SIG-rules-authors#11 (comment) Of course, that didn't stop it from breaking again: https://github.com/orgs/community/discussions/45830 |
Beta Was this translation helpful? Give feedback.
-
|
Please see https://github.com/orgs/community/discussions/46034 for the latest discussion on stability or not for these archives. |
Beta Was this translation helpful? Give feedback.
-
|
Understood. It was not so much asking for a guarantee as knowing how the process is implemented. Thanks! |
Beta Was this translation helpful? Give feedback.
What it sounds like you’re asking for is a 100% guarantee that the release tarballs will not change. That’s something that we aren’t going to guarantee. 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.
I hope that helps!