Hash change for v1.2.2 source code archive

[WangEdward]

Hi! I am working on migrating the OpenJDK to version 22 for Homebrew (a Mac package manager).

During the CI test of the software that depends on OpenJDK, it seems that the checksum of metals' source archive for version 1.2.2 has been changed. (from 8c342965383406e28799187b4ca5349c8f486171da31ecca56bc197f2b8d1c14 to 5b9998b9d3d6e224d911f83584859f626bd74180f8bf2b0d464982a8ccf470f8)

The URL to source archive brew uses is: https://github.com/scalameta/metals/archive/refs/tags/v1.2.2.tar.gz
Logs to CI: https://github.com/Homebrew/homebrew-core/actions/runs/8602702349/job/23584694069?pr=168294#step:3:3412
The pull request that bumps metals to 1.2.2 in Homebrew (2024-02-15T19:30:31Z): Homebrew/homebrew-core#162868

I do not see any change made on tag v1.2.2 after 2024-02-14. If you have any idea why this happens, please let me know.

Thanks for your help!

[tgodzik]

Thanks for raising this! We haven''t really changed the the tar it's pointing to and that tar is created by github itself, so this is quite surprising. Could it be a mistake on the contributors side? We don't have anything set up automatic and is done by other contributors not maintaining metals itself. Might be worth asking on that PR maybe?

[SMillerDev]

As part of CI the file is validated to have the correct checksum. Possible scenarios for a changing checksum of a generated tarbal include:

• you've retagged the version
• your repo was compromised and someone retagged it for you.

[WangEdward]

I also feel quite confused😂. The old hash is automatically calculated, and it passes the CI in the PR I mentioned above, which means the hash was the old one at that moment. (@chenrui333 , please also look into this)

[tgodzik]

Looks like it might have been a mistake then. I think there was an issue with the tag that it was on a commit that did not belong to the repository, which caused some other issues done the line. It might have been me to set it right and I wasn't aware that this would cause issues.

Although, we didn't change the release itself, just modified the tag to point to the correct commit. Would github update the release automatically and cause the issue at hand?

[tgodzik]

This is the other commit 3c75efc

The commit was later merged via rebase and that probably made it change the hash I guess, which means that commit would not not exist in the main repo.

So the question is, could we update the hash to fix that?

[WangEdward]

This is the diff of `libexec/lib/metals_2.13-1.2.2/scala/meta/internal/metals/BuildInfo$.class`

The left one is the build generated on 2024-02-15 by homebrew, and the right one is my built today.

It is the only difference other than the dependency difference of semanticdb.

My guess is that someone mistyped 1.2.2 to 1.2.3 and changed it back later.

[WangEdward]

So the question is, could we update the hash to fix that?

I think it is possible. I already opened Homebrew/homebrew-core#168404 .
Homebrew maintainers should be able to approve it as long as they know the hash for new tar.gz is authentic.

[tgodzik]

Looks to be consistent with what I found. We usually tag the version before the release notes and related updates, but the other contributed tagged the not yet merged commit with those updates. One of the updates is changing the default snapshot version, which is put automatically into code.

I wasn't aware that brew actually built the code and that's how the sha is calculated. I can try an update to the other commit with those changes merged. That might help?

[tgodzik]

Ok, it's ok to change the hash that would be awesome, sorry for the trouble! I will confirm on the PR