https://github.com/bazel-contrib/SIG-rules-authors/issues/11 Skip to content Toggle navigation Sign up * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code + Explore + All features + Documentation + GitHub Skills + Blog * Solutions + For + Enterprise + Teams + Startups + Education + By Solution + CI/CD & Automation + DevOps + DevSecOps + Case Studies + Customer Stories + Resources * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles + Repositories + Topics + Trending + Collections * Pricing [ ] * # In this repository All GitHub | Jump to | * No suggested jump to results * # In this repository All GitHub | Jump to | * # In this organization All GitHub | Jump to | * # In this repository All GitHub | Jump to | Sign in Sign up {{ message }} bazel-contrib / SIG-rules-authors Public * * Notifications * Fork 7 * Star 18 * Code * Issues 28 * Pull requests 3 * Discussions * Actions * Projects 0 * Security * Insights More * Code * Issues * Pull requests * Discussions * Actions * Projects * Security * Insights 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. Pick a username [ ] Email Address [ ] Password [ ] [ ] Sign up for GitHub 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 Jump to bottom Should rulesets distribute a pre-built artifact rather than rely on GitHub source/release archive #11 Closed alexeagle opened this issue Nov 16, 2021 * 66 comments Closed Should rulesets distribute a pre-built artifact rather than rely on GitHub source/release archive #11 alexeagle opened this issue Nov 16, 2021 * 66 comments Comments @alexeagle Copy link Contributor alexeagle commented Nov 16, 2021 Rules ought to distribute an artifact that doesn't contain references to development-time dependencies, and omits testing code and examples. This means the distribution can be broken if files are missing. In addition, rules ought to integration-test against all supported bazel versions. So there should be some bazel-in-bazel test that consumes the HEAD distribution artifact and tests that the examples work. Right now there are a few ways. rules_nodejs and rules_python have a built-in integration test runner. rules_go has a special go_bazel_test rule. The text was updated successfully, but these errors were encountered: All reactions @alexeagle Copy link Contributor Author alexeagle commented Nov 16, 2021 See https://docs.google.com/document/d/ 1s_8AihGXbYujNWU_VjKNYKQb8_QGGGq7iKwAVQgjbn0/edit?usp=sharing for discussion around the requirements for testing against multiple Bazel versions. All reactions Sorry, something went wrong. @aherrmann Copy link Member aherrmann commented Nov 17, 2021 Rules ought to distribute an artifact that doesn't contain references to development-time dependencies, and omits testing code and examples. Could you motivate this? It is not clear to me why this should be mandated. If the motivation is that users of a rule set should not depend on dev-dependencies of that rule set, then this can be achieved without a dedicated distribution artifact. E.g. in rules_haskell dev-dependencies are only pulled in in rules_haskell's own WORKSPACE file, while regular dependencies are pulled in by the rules_haskell_dependencies macro that users are meant to call as well. Also the upcoming Bazel modules mechanism has a notion of dev-dependencies IIRC. I think it is a plus that Bazel rule sets can be imported directly from their source repository at any commit without needing to generate a distribution artifact first. This makes it very easy to pull in a non-release commit of a rule set that contains a needed fix. If rule sets are only intended to be used from distribution artifacts, then this use-case is no longer necessarily supported, as a rule set may depend on generated files that are only included in the distribution artifact. Either way, I don't think this should be mandated without the required tooling being available. See below. --------------------------------------------------------------------- Regarding bazel-in-bazel tests. I agree that this would be useful to have. We have looked into this for rules_haskell and in this context looked into a Gazelle extension to generate filegroup targets capturing all files required to run the rule set. (The same would be useful for generating distribution artifacts.) We based our efforts on Gazelle's test_filegroup. However, we found it to be lacking for our use-case. Issues that come to mind are that it does not respect .gitignore or .bazelignore files, leading to invalid file inclusions of e.g. embedded workspaces for integration testing or user local configuration files like .bazelrc.local. Or that it assumes that every directory is a Bazel package, which is not a valid assumption and breaks labels like //my/pkg:src/some/source/ file. It would be great to have general purpose versions of test_filegroup and go_bazel_test available for any rule set to use. I'd view this as a prerequisite for this recommendation. All reactions Sorry, something went wrong. @alexeagle Copy link Contributor Author alexeagle commented Nov 17, 2021 Mostly the pre-built distribution artifact is required to get a stable checksum. If you rely on GitHub's generated .tgz source archives, you get a breakage when GitHub makes OS updates on their servers that create those archives. It's also handy to avoid someone building @some_ruleset//... and breaking because there's a load statement there from a dev dependency. I agree that it's desirable that the distro artifact is same-shaped as the source repo (generally just a subset of files) so that it's easy to opt-in to a HEAD dependency. We made that mistake with rules_nodejs and are working to undo that. All reactions Sorry, something went wrong. @ittaiz Copy link ittaiz commented Nov 21, 2021 Hi , Few more thoughts on my end: 1. Having bazel in bazel tests is super valuable also for internal rules authors. I've had this need a few times. 2. Just in case someone doesn't know then there's the bazel integration testing repo. I've failed to keep it alive but I think a lot of the concepts there are valuable. 3. +1 for being able to use commits from github. In practice we only had 1 issue with the checksums in 5-6 years and I can't count how many builds. 2 rotemmiz and aherrmann reacted with thumbs up emoji All reactions * 2 reactions Sorry, something went wrong. @alexeagle Copy link Contributor Author alexeagle commented Nov 21, 2021 @ittaiz what do you think about the SIG contributing or owning the current integration test repo in bazelbuild org? All reactions Sorry, something went wrong. @ittaiz Copy link ittaiz commented Nov 21, 2021 Be happy to add contributors and even hand ownership over if you feel that's important All reactions Sorry, something went wrong. @aherrmann Copy link Member aherrmann commented Nov 24, 2021 Mostly the pre-built distribution artifact is required to get a stable checksum. If you rely on GitHub's generated .tgz source archives, you get a breakage when GitHub makes OS updates on their servers that create those archives. Is this still true? I haven't found official GitHub documentation stating that the archives are reproducible, but I have found this reproducible-builds thread pointing out that Github uses git archive and that git archive is designed to be reproducible. Just as a quick test I compared the GH archive to a git archive created locally on rules_haskell. $ curl -L https://github.com/tweag/rules_haskell/archive/455d9e6e8212f0bb73cd6e5437b0f5ce093e44be.tar.gz|sha256sum - 6841e554566d0c326beac84442dd776c49fac7d6059fef4728e75ae37c8e92cc - $ git clone https://github.com/tweag/rules_haskell; cd rules_haskell; git archive --format=tar --prefix=rules_haskell-455d9e6e8212f0bb73cd6e5437b0f5ce093e44be/ 455d9e6e8212f0bb73cd6e5437b0f5ce093e44be | gzip > tarball.tgz; sha256sum tarball.tgz 6841e554566d0c326beac84442dd776c49fac7d6059fef4728e75ae37c8e92cc tarball.tgz As you can see, the SHA256 is identical. This suggests that the archive is generated reproducibly. Anecdotally, the only instance where I encountered issues with a changing commit hash in the last couple years was kubernetes/ kubernetes#99376. In this case the change was due to a problematic .gitattributes configuration. All reactions Sorry, something went wrong. This was referenced Nov 25, 2021 bazel_skylib: Register unittest toolchains bazelbuild/ bazel-central-registry#33 Merged Initial contribution of code from aspect-build/bazel_rules_template bazel-contrib/rules-template#1 Merged @alexeagle Copy link Contributor Author alexeagle commented Nov 29, 2021 @aherrmann I've followed this guidance ever since Jay Conrod made a big deal out of it in rules_go and bazel_gazelle. bazelbuild/rules_go #2340 suggests maybe some GitHub URLs are reliable and some are not? There is yet another reason I think rules should build their own distribution archive, which is that you can calculate your own checksum to produce the WORKSPACE snippet in the release process before shipping the commits to GitHub. All reactions Sorry, something went wrong. @aherrmann Copy link Member aherrmann commented Nov 30, 2021 @aherrmann I've followed this guidance ever since Jay Conrod made a big deal out of it in rules_go and bazel_gazelle. bazelbuild/ rules_go#2340 suggests maybe some GitHub URLs are reliable and some are not? Thanks for the pointer, I dug into this a little. I've attached the details in the end, in short: I don't think this was a case of the Github generated source archive changing. Instead, it looks to me as though this was a mixup between the SHA for the Github generated source archive and the release artifact. So, I don't think this is evidence to support the claim that Github source archives are non-reproducible. There is yet another reason I think rules should build their own distribution archive, which is that you can calculate your own checksum to produce the WORKSPACE snippet in the release process before shipping the commits to GitHub. The same can be achieved using git archive --format=tar.gz --prefix= $NAME-$TAG/ $TAG | sha256sum when using source archives. To be clear, I'm not saying one should not use release artifacts. But, I am saying that I don't see why it should be mandated that everyone use them without a good technical reason to motivate that mandate. I haven't seen such a reason, yet. As mentioned above, there are upsides to the source archive approach and costs to the release artifact approach. --------------------------------------------------------------------- Details: If we take a look at the changes in the PR we see --- a/multirun/deps.bzl +++ b/multirun/deps.bzl @@ -4,7 +4,7 @@ def multirun_dependencies(): _maybe( http_archive, name = "bazel_skylib", - sha256 = "2ef429f5d7ce7111263289644d233707dba35e39696377ebab8b0bc701f7818e", + sha256 = "2ea8a5ed2b448baf4a6855d3ce049c4c452a6470b1efd1504fdb7c1c134d220a", strip_prefix = "bazel-skylib-0.8.0", urls = ["https://github.com/bazelbuild/bazel-skylib/archive/0.8.0.tar.gz"], ) The 0.8.0 release has a release artifact and of course the generated source archive. If we look at the SHAs of each of these we find $ curl -L https://github.com/bazelbuild/bazel-skylib/releases/download/0.8.0/bazel-skylib.0.8.0.tar.gz|sha256sum - 2ef429f5d7ce7111263289644d233707dba35e39696377ebab8b0bc701f7818e - $ curl -L https://github.com/bazelbuild/bazel-skylib/archive/refs/tags/0.8.0.tar.gz|sha256sum - 2ea8a5ed2b448baf4a6855d3ce049c4c452a6470b1efd1504fdb7c1c134d220a - I.e. the old hash was the hash of the release artifact and the new hash is the hash of the generated source archive. If we compare the contents of these two archives we find $ curl -L https://github.com/bazelbuild/bazel-skylib/releases/download/0.8.0/bazel-skylib.0.8.0.tar.gz|tar ztv|head -n 5 ... drwxrwxr-x root/root 0 2019-03-20 18:13 .bazelci/ -rw-rw-r-- root/root 2348 2019-03-20 18:13 .bazelci/presubmit.yml -rw-rw-r-- root/root 9 2019-03-20 18:13 .gitignore -rw-rw-r-- root/root 308 2019-03-20 18:13 AUTHORS -rw-rw-r-- root/root 1002 2019-03-20 18:13 BUILD $ curl -L https://github.com/bazelbuild/bazel-skylib/archive/refs/tags/0.8.0.tar.gz|tar ztv|head -n 5 ... drwxrwxr-x root/root 0 2019-03-20 18:13 bazel-skylib-0.8.0/ drwxrwxr-x root/root 0 2019-03-20 18:13 bazel-skylib-0.8.0/.bazelci/ -rw-rw-r-- root/root 2348 2019-03-20 18:13 bazel-skylib-0.8.0/.bazelci/presubmit.yml -rw-rw-r-- root/root 9 2019-03-20 18:13 bazel-skylib-0.8.0/.gitignore -rw-rw-r-- root/root 308 2019-03-20 18:13 bazel-skylib-0.8.0/AUTHORS I.e. the release artifact has no prefix, while the generated source archive does have the standard - prefix. The change is from Jan 2020, I'm pretty sure Github generated source archives had the - prefixes at that time as well. So, it looks like the old hash was never that of a Github generated source archive, but that of the release artifact. It seems the issue here was most likely not that the generated source archive changed, but that the wrong hash was written into multirun/deps.bzl before. For reference, I can produce an equivalent to the Github generated source archive with the same hash on my machine today: $ git archive --format=tar.gz --prefix=bazel-skylib-0.8.0/ 0.8.0 | sha256sum 2ea8a5ed2b448baf4a6855d3ce049c4c452a6470b1efd1504fdb7c1c134d220a - If I try to reproduce the release artifact I get a different hash than the release artifact uploaded on $ git archive --format=tar.gz 0.8.0 | sha256sum a04a79bca280f759ec2339c035e19d1f249616c38a352f9fdb8837a7c0ea2f7c - But, comparing this generated prefix-less tarball to the release tarball I find $ curl -L https://github.com/bazelbuild/bazel-skylib/releases/download/0.8.0/bazel-skylib.0.8.0.tar.gz > released.tar.gz $ git archive --format=tar.gz 0.8.0 > generated.tar.gz $ diffoscope released.tar.gz generated.tar.gz --- released.tar.gz +++ generated.tar.gz +-- filetype from file(1) | @@ -1 +1 @@ | -gzip compressed data, last modified: Wed Mar 20 18:02:49 2019, max compression | +gzip compressed data, from Unix | --- released.tar +-- +++ generated.tar | +-- filetype from file(1) | | @@ -1 +1 @@ | | -POSIX tar archive (GNU) | | +POSIX tar archive So, the difference comes down to the release artifact containing slightly different headers including a timestamp. 2 brentleyjones and cgrindel reacted with thumbs up emoji All reactions * 2 reactions Sorry, something went wrong. @alexeagle alexeagle changed the title [DEL:Recommend how rulesets can integration-test their distribution artifact:DEL] [INS:Should rulesets distribute a pre-built artifact rather than rely on GitHub source/release archive:INS] Nov 30, 2021 @alexeagle Copy link Contributor Author alexeagle commented Nov 30, 2021 Great discussion. I think this issue ended up conflating two things. We agree that we need bazel-in-bazel integration testing of rules, let's move that to a new issue since the bulk of discussion here was about the release archive and that's just one motivation for bazel-in-bazel testing. 2 cgrindel and aherrmann reacted with thumbs up emoji All reactions * 2 reactions Sorry, something went wrong. @alexeagle alexeagle mentioned this issue Nov 30, 2021 Provide a general facility for bazel-in-bazel integration testing #25 Closed @alexeagle alexeagle mentioned this issue Dec 11, 2021 Simplify distro/release aspect-build/bazel-lib#12 Closed @alexeagle Copy link Contributor Author alexeagle commented Dec 14, 2021 I've updated all my repos, as well as the rules-template, to reflect that GitHub produces a stable SHA for the artifacts it serves. 1 aherrmann reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. @alexeagle alexeagle closed this as completed Dec 14, 2021 @fmeum fmeum mentioned this issue Dec 15, 2021 Allow rulesets to adopt rules_license bazelbuild/rules_license#9 Closed @fmeum Copy link fmeum commented Feb 1, 2022 Sorry to revive this closed issue, but I just encountered a situation in which the SHA of a GitHub-provided archive changed over time and thus ended up breaking the build. Over at https://github.com/CodeIntelligenceTesting/jazzer, we use the following dependency on abseil-cpp: maybe( http_archive, name = "com_google_absl", sha256 = "5e1cbf25bf501f8e37866000a6052d02dbdd7b19a5b592251c59a4c9aa5c71ae", strip_prefix = "abseil-cpp-f2dbd918d8d08529800eb72f23bd2829f92104a4", url = "https://github.com/abseil/abseil-cpp/archive/f2dbd918d8d08529800eb72f23bd2829f92104a4.zip", ) An hour ago, CI runs started to fail with this error: ERROR: /home/runner/work/jazzer/jazzer/driver/BUILD.bazel:21:11: //driver:fuzzed_data_provider depends on @com_google_absl//absl/strings:str_format in repository @com_google_absl which failed to fetch. no such package '@com_google_absl//absl/strings': java.io.IOException: Error downloading [https://github.com/abseil/abseil-cpp/archive/f2dbd918d8d08529800eb72f23bd2829f92104a4.zip] to /home/runner/.cache/bazel/_bazel_runner/6bc610921f14939de4c55cf170d55a62/external/com_google_absl/temp17765729958342005876/f2dbd918d8d08529800eb72f23bd2829f92104a4.zip: Checksum was 70203fec1c4823d4fe689f1c413bc7a0e6b4556dbd55b5ac40fc8862bacc0dcb but wanted 5e1cbf25bf501f8e37866000a6052d02dbdd7b19a5b592251c59a4c9aa5c71ae I attached both the ZIP file that can currently be obtained from https://github.com/abseil/abseil-cpp/archive/ f2dbd918d8d08529800eb72f23bd2829f92104a4.zip ( abseil-cpp-f2dbd918d8d08529800eb72f23bd2829f92104a4.github-new.zip) and the ZIP file that was previously generated by GitHub and that I obtained from my local repository cache ( abseil-cpp-f2dbd918d8d08529800eb72f23bd2829f92104a4.github-old.zip). Running diffoscope on these files shows that the mtimes hour changed: ... |- Archive contents identical but files differ, possibly due to different compression levels. Falling back to binary comparison. +-- zipinfo -v {} | @@ -28,15 +28,15 @@ | file system or operating system of origin: MS-DOS, OS/2 or NT FAT | version of encoding software: 0.0 | minimum file system compatibility required: MS-DOS, OS/2 or NT FAT | minimum software version required to extract: 1.0 | compression method: none (stored) | file security status: not encrypted | extended local header: no | - file last modified on (DOS date/time): 2021 Nov 11 00:09:50 | + file last modified on (DOS date/time): 2021 Nov 11 08:09:50 | file last modified on (UT extra field modtime): 2021 Nov 11 08:09:50 local | file last modified on (UT extra field modtime): 2021 Nov 11 08:09:50 UTC | 32-bit CRC value (hex): 00000000 | compressed size: 0 bytes | uncompressed size: 0 bytes | length of filename: 52 characters | length of extra field: 9 bytes ... @aherrmann Do you have an idea how this could happen and whether tar.gz would not have been prone to this? All reactions Sorry, something went wrong. @fmeum fmeum mentioned this issue Feb 1, 2022 Build broken by change in GitHub source ZIP generation bazelbuild/ rules_fuzzing#200 Open @fmeum Copy link fmeum commented Feb 1, 2022 Looks like the change has been rolled back, so this might have been an honest bug. All reactions Sorry, something went wrong. @brentleyjones Copy link brentleyjones commented Feb 1, 2022 And they said that they would insure the checksum doesn't change in the future. So I think this might even harden the case that we can rely on the checksum. All reactions Sorry, something went wrong. @fmeum Copy link fmeum commented Feb 1, 2022 @brentleyjones That's great to know. Could you point me to the place where they confirmed that? All reactions Sorry, something went wrong. @brentleyjones Copy link brentleyjones commented Feb 1, 2022 So not as strong as a guarantee as I originally read it as, but it seems the rollback was related to the checksum change: https:// twitter.com/tgummerer/status/1488493440103030787 All reactions Sorry, something went wrong. @fmeum Copy link fmeum commented Feb 1, 2022 There is https://twitter.com/tgummerer/status/1488493481874055173 though, so depending on archives for individual commits is unsafe. All reactions Sorry, something went wrong. @brentleyjones Copy link brentleyjones commented Feb 1, 2022 Yikes All reactions Sorry, something went wrong. @alexeagle Copy link Contributor Author alexeagle commented Feb 1, 2022 I think we have to push hard and escalate (like Ulf did) to point out that GH is running a package repo and the world relies on it for supply-chain safety... All reactions Sorry, something went wrong. @alexeagle Copy link Contributor Author alexeagle commented Feb 1, 2022 /cc @tgummerer All reactions Sorry, something went wrong. @alexeagle alexeagle reopened this Feb 1, 2022 @Wyverald Wyverald mentioned this issue Feb 1, 2022 Bazel crashes fetching http_archive dependency bazelbuild/bazel#14682 Closed 82 hidden items Load more... @rbberger rbberger mentioned this issue Jan 30, 2023 GitHub tarball checksum changed, broke automatic downloads in CMake (reverted by GitHub for now) lammps/lammps#3626 Open @nekopsykose Copy link nekopsykose commented Jan 30, 2023 While we are updating our SHAs, we should probably just migrate to Gitlab, right? anecdotal and i cannot point to anything specific currently, but i have seen some "compression changed on generated tarballs" on gitlab too (between some updates). i don't think any of these systems are designed with a perfect guarantee for this ("this" being hash-stable tarballs), we just got here by circumstance. 2 joer14 and timsutton reacted with thumbs up emoji All reactions * 2 reactions Sorry, something went wrong. @joer14 Copy link joer14 commented Jan 30, 2023 While we are updating our SHAs, we should probably just migrate to Gitlab, right? Is that the current recommendation for people who want more reliability? 1 kkirsche reacted with thumbs down emoji All reactions * 1 reaction Sorry, something went wrong. @fmeum Copy link fmeum commented Jan 30, 2023 @bk2204 https://support.github.com/ticket/personal/0/1485189 (not visible publicly) made a clear commitment that the /archive/refs/tags /$tag endpoint would provide archives with stable hashes and should be relied upon for that purpose. I specifically asked for confirmation of this twice and received it. Happy to share the full conversation I had with support. 9 brentleyjones, rob-pomelo, binoche9, willeccles, mattem, marcelofabri, MarkusZoppelt, nico-abram, and kkirsche reacted with thumbs up emoji All reactions * 9 reactions Sorry, something went wrong. jerrymarino added a commit to bazel-ios/rules_swift that referenced this issue Jan 30, 2023 @jerrymarino Bump shas of non-release rules_swift deps ... 7d129d0 rules_swift points at a number of non release depenencies. Longer term rules_swift should move these depenecies to release URLS to use github's offical annoucment. Github gaurentees the release archives. Per github's offical comms > The default compression for Git archives has recently changed. > As result, archives downloaded from GitHub may have different checksums > even though the contents are completely unchanged. https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/ bazel-contrib/SIG-rules-authors#11 (comment) @jerrymarino jerrymarino mentioned this issue Jan 30, 2023 Bump shas of non-release rules_swift deps bazelbuild/rules_swift#992 Closed @eli-schwartz eli-schwartz mentioned this issue Jan 30, 2023 abseil-cpp: Fix source_hash of 20220623.0 release archive mesonbuild/ wrapdb#884 Open @vtbassmatt Copy link vtbassmatt commented Jan 30, 2023 Hey folks. I'm the product manager for Git at GitHub. We're sorry for the breakage, we're reverting the change, and we'll communicate better about such changes in the future (including timelines). 18 austinpray-mixpanel, f0rmiga, luispadron, TheGrizzlyDev, groodt, andyleap, bduffany, picsel2, Sazu-bit, yuriydee, and 8 more reacted with thumbs up emoji 6 austinpray-mixpanel, groodt, drfloob, andyleap, jayconrod, and BillyONeal reacted with laugh emoji 19 joer14, titanous, f0rmiga, binoche9, gabware, lincoln-replit, lbcjbb, Hopobcn, past-due, RyanTheOptimist, and 9 more reacted with hooray emoji [?] 103 Arcnor, ericrafalovsky, esjolander, firthm01, andyleap, quyykk, jonathanlking, tdibattista, mclarsen, kormide, and 93 more reacted with heart emoji 8 austinpray-mixpanel, metasyn, f0rmiga, TheGrizzlyDev, andyleap, marcelofabri, lbcjbb, and BillyONeal reacted with rocket emoji 2 f0rmiga and pnacht reacted with eyes emoji All reactions * 18 reactions * 6 reactions * 19 reactions * [?] 103 reactions * 8 reactions * 2 reactions Sorry, something went wrong. @nektro Copy link nektro commented Jan 30, 2023 did GitHub remove the staff tag from profiles? there's allegedly like 4 staff members in this thread and no one has the badge 13 williamjallen, luispadron, Xe, camm73, brentleyjones, dmitshur, clonsdale-canva, quyykk, mihaimaruseac, zneix, and 3 more reacted with thumbs up emoji All reactions * 13 reactions Sorry, something went wrong. @vtbassmatt Copy link vtbassmatt commented Jan 30, 2023 We updated our Git version which made this change for the reasons explained. At the time we didn't foresee the impact. We're quickly rolling back the change now, as it's clear we need to look at this more closely to see if we can make the changes in a less disruptive way. Thanks for letting us know. Also re: Staff badge, here's what I see in this thread: image All reactions Sorry, something went wrong. copybara-service bot pushed a commit to google/gvisor that referenced this issue Jan 30, 2023 @ayushr2 @gvisor-bot Update SHA256 for dependencies that use the automated "Source code (t... ... a0efae0 ...ar.gz)". There is discussion about this issue in bazel-contrib/SIG-rules-authors#11. But basically GitHub does not provide stability guarantees around "the automated 'Source code (tar.gz)' and 'Source code (zip)' links, as well as any automated archives we generate". So the checksums for such artifacts can change, like they did this morning. The cause is: "the thing that has changed is the compression, since Git has switched from using gzip to an internal call to zlib". So we just update to the new checksums for the 4 dependencies affected. GRPC dependency is also broken because it has such an outdated checksum for com_google_googletest in grpc/bazel/grpc_deps.bzl. Luckily, GRPC only adds that dependency if it doesn't already exist. So we can sidestep this issue by moving our (unbroken) com_google_googletest dependency above GRPC dependency. Furthermore, a force pushed commit broke exports. Fixed that. Lets continue developing. PiperOrigin-RevId: 505796815 @copybara-service copybara-service bot mentioned this issue Jan 30, 2023 Update SHA256 for dependencies that use the automated "Source code (tar.gz)". google/gvisor#8456 Open @archoversight Copy link archoversight commented Jan 30, 2023 Meta, @vtbassmatt this is what we normal users see. Screenshot 2023-01-30 at 3 24 25 PM 51 Naddiseo, Xe, rainwoodman, luispadron, quyykk, ramuuns, willeccles, codyoss, lincoln-replit, gkelly, and 41 more reacted with thumbs up emoji All reactions * 51 reactions Sorry, something went wrong. @vtbassmatt Copy link vtbassmatt commented Jan 30, 2023 this is what normal users see Huh! I don't work on frontend stuff, so that's a mystery to me 9 zneix, mmailhos, kevinkouketsu, joel-canva, kenhacanva, hen-x, Mx7f, kkirsche, and charlesoconor reacted with laugh emoji [?] 4 luispadron, kenhacanva, kkirsche, and charlesoconor reacted with heart emoji All reactions * 9 reactions * [?] 4 reactions Sorry, something went wrong. @jerrymarino Copy link jerrymarino commented Jan 30, 2023 @vtbassmatt awesome thank you kindly [?] Will github provide stability guarantees around the non release tarball / zip URLs going forward? 6 luispadron, kormide, zneix, JamesMBartlett, mihaimaruseac, and ilanKeshet reacted with thumbs up emoji All reactions * 6 reactions Sorry, something went wrong. copybara-service bot pushed a commit to google/gvisor that referenced this issue Jan 30, 2023 @ayushr2 @gvisor-bot Update SHA256 for dependencies that use the automated "Source code (t... ... a5bf7a9 ...ar.gz)". There is discussion about this issue in bazel-contrib/SIG-rules-authors#11. But basically GitHub does not provide stability guarantees around "the automated 'Source code (tar.gz)' and 'Source code (zip)' links, as well as any automated archives we generate". So the checksums for such artifacts can change, like they did this morning. The cause is: "the thing that has changed is the compression, since Git has switched from using gzip to an internal call to zlib". So we just update to the new checksums for the 4 dependencies affected. GRPC dependency is also broken because it has such an outdated checksum for com_google_googletest in grpc/bazel/grpc_deps.bzl. Luckily, GRPC only adds that dependency if it doesn't already exist. So we can sidestep this issue by moving our (unbroken) com_google_googletest dependency above GRPC dependency. Furthermore, a force pushed commit broke exports. Fixed that. Lets continue developing. PiperOrigin-RevId: 505796815 @f0rmiga Copy link Member f0rmiga commented Jan 30, 2023 Thank you, @vtbassmatt. May I suggest a regression test for this? 5 bduffany, Ryang20718, brentleyjones, joer14, and gkelly reacted with thumbs up emoji 3 luispadron, Ryang20718, and zneix reacted with laugh emoji All reactions * 5 reactions * 3 reactions Sorry, something went wrong. @camm73 camm73 mentioned this issue Jan 30, 2023 [package] aws-c-common/0.8.2: sha256 signature failed conan-io/ conan-center-index#15574 Open @jmacdonald-Ocient Copy link jmacdonald-Ocient commented Jan 30, 2023 @vtbassmatt For those of us who dutifully updated our checksums in response to the original change, can you give us a timeline for the rollback so we can try to time rolling back our updates? I totally understand we are in the minority and rolling back the change is the right move, but of course the new interface was live, Hyrum's law and all that. All reactions Sorry, something went wrong. @vtbassmatt Copy link vtbassmatt commented Jan 30, 2023 @jerrymarino too soon to commit to anything in particular (except "we will DEFINITELY communicate better"). There are good reasons on both sides. @jmacdonald-Ocient the rollback is imminent, just winding its way through automated testing. I don't know for sure how long it will take to show up, I'm sorry. 8 picsel2, nektro, gkelly, groodt, nico-abram, bezhermoso, kaix-canva, and anthony-canva reacted with rocket emoji All reactions * 8 reactions Sorry, something went wrong. @aneeshusa Copy link aneeshusa commented Jan 30, 2023 Thanks GitHub staff for the quick response, looking forward to the follow-up communication. Idea on better communication going forward - could you please add a hint in the UI right by the download links that links to docs on what is/isn't stable and possibly best practices on getting stable artifacts and checksumming them? e.g. a help icon you can hover over with a tooltip or that links to the docs. IME this form of contextual help/communication is really beneficial for customers that may not follow the blog, think to search the docs, etc. as it's right in the point of use. 2 kail and smason-apex reacted with thumbs up emoji All reactions * 2 reactions Sorry, something went wrong. @drfloob drfloob mentioned this issue Jan 30, 2023 [fix] Change expected checksums of Github archives grpc/grpc#32239 Closed @palmskog palmskog mentioned this issue Jan 30, 2023 GitHub tarball checksum changes coq/opam-coq-archive#2458 Open @xclaesse xclaesse mentioned this issue Jan 30, 2023 Checksum of release archive has changed abseil/abseil-cpp#1373 Open @vlovich Copy link vlovich commented Jan 30, 2023 If the checksum isn't stable, after the community is migrated, I would recommend that a random value is injected every time to really drive this point home so that no one reacquires an incorrect dependency. Hyrum's Law shows that documenting an interface as unstable is insufficient if in practice it's largely stable. 4 ilanKeshet, titanous, fmeum, and jayconrod reacted with thumbs up emoji 1 mihaimaruseac reacted with laugh emoji [?] 1 lrewega reacted with heart emoji All reactions * 4 reactions * 1 reaction * [?] 1 reaction Sorry, something went wrong. @coryan coryan mentioned this issue Jan 30, 2023 sha256 hash changed for googleapis archive googleapis/ google-cloud-cpp#10696 Closed @ilanKeshet Copy link ilanKeshet commented Jan 30, 2023 Hey folks. I'm the product manager for Git at GitHub. We're sorry for the breakage, we're reverting the change, and we'll communicate better about such changes in the future (including timelines). Oh wow, what a wild ride, i'm so glad you are reverting it Please note that not everything can be migrated to pointing at a release package easily, a lot of the checksum errors I've experienced were in third party plugin/rule code we have no direct control over. Some pointing to on-the-fly tar.gz generated source archive from specific historical revisions and such. obviously we'd do our part in migrating away and upgrading such dependencies but still this is quite a genuine threat and one that is hard to validate. please take such concerns under consideration when rolling out a solution All reactions Sorry, something went wrong. @kthui kthui mentioned this issue Jan 30, 2023 SHA256 Hash changes for v1.0.1 jupp0r/prometheus-cpp#632 Closed @SpaceIm SpaceIm mentioned this issue Jan 30, 2023 librdkafka: add version 2.0.2, update libcurl conan-io/ conan-center-index#15393 Merged 3 tasks @vtbassmatt Copy link vtbassmatt commented Jan 30, 2023 Those files are generated new each time (with some caching - an hour I think). We told Git to use the old settings instead of its new default, so they'll start getting generated with the old hashes again. I'm told the roll-out is complete, modulo resetting those caches. All reactions Sorry, something went wrong. Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Assignees No one assigned Labels None yet Projects None yet Milestone No milestone Development No branches or pull requests 30 participants @alexeagle @mathstuf @jfirebaugh @timsutton @brentleyjones @vlovich @wyattanderson @bk2204 @vtbassmatt @aherrmann @joer14 @jerrymarino @ittaiz @BillyONeal @aneeshusa @f0rmiga @willeccles @kentonv @fmeum @nektro and others Footer (c) 2023 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time. You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.