Checksum of https://github.com/google/googletest/archive/refs/tags/release-1.11.0.zip has recently changed.

[alan-davies-se]

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

[Markus Felix]

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"

[Henner Zeller]

Dito in Verible: chipsalliance/verible#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.

[Henner Zeller]

Sounds like some rollback is in progress: https://twitter.com/tgummerer/status/1488493440103030787

[alan-davies-se]

I can confirm our CI is now working again so it seems like the sha is back to its old value.