Closed alan-davies-se closed 2 years ago
We are seeing the same behaviour in our bazel ci
The old checksum, as hard coded has been: "353571c2440176ded91c2de6d6cd88ddd41401d14692ec1f99e35d013feda55a"
while requesting a new download of the same file yields another sha256sum of "63afcb1690b2139b2d9c7ad1df3de87697530fb1fd6869622cff26c77a3b0cfb"
Dito in Verible: https://github.com/chipsalliance/verible/issues/1168
We compared the content of each file, and it looks exactly the same as before, but the timestamps in the zip file changed. This might be due to github re-packaging the files ? I guess we need to ask github if this was an accidental move. We see the hashes somewhat flapping, this might indicate some of their serving infrastructure is returning different files.
Sounds like some rollback is in progress: https://twitter.com/tgummerer/status/1488493440103030787
I can confirm our CI is now working again so it seems like the sha is back to its old value.
I am pretty confident this is the case because we use cmake to fetch the following url:
https://github.com/google/googletest/archive/refs/tags/release-1.11.0.zip
We had a hard coded sha384 of:
93d8ce0bc1ab360c6ed1ef424cf8d2828b4911e9816f0b2eb7adabae0065204bc5e4115e4b5e361898ec8f052bfeced5
Recently our continuous integration builds are failing because the actual sha is now:
b0062b7d172587326f2b0a279d26d83aaf6e8ed4197709f596805ad0d16229d43e8c2d5bceae33d1ae874e5b7d57f717
Can you please explain how and why this has changed.
Thanks