Version number becomes 0.0.0 when commit count exceeds 256

[olafurpg]

See https://scalameta.org/metals/docs/editors/vscode.html#using-latest-metals-snapshot

I expected the version number to start with v0.7.6. I'm unable to reproduce locally on my computer, our CI does the releases. You can try to checkout the scalameta/metals repo at commit scalameta/metals@539450f

It looks like this branch is being hit
https://github.com/dwijnand/sbt-dynver/blob/569cd975e77bbfd2163ce792b131dcdd2832321e/src/main/scala/sbtdynver/DynVerPlugin.scala#L113

Any idea what might be going on?

[raboof]

perhaps CI did a 'shallow' git checkout and didn't fetch enough history to find the previous tag?

[dwijnand]

^

There, in theory, would be a sanity check you opt into for that (https://github.com/dwijnand/sbt-dynver#sanity-checking-the-version) but it needs attention (#132).

[dwijnand]

Oh, and git fetch --unshallow is a CI agnostic way to avoid this issue.

[olafurpg]

Thank you for the help! Let's see how that works out scalameta/metals#1143

[olafurpg]

git fetch --unshallow seems to have fixed the issue!

] 	published mtags_2.13.1 to https://oss.sonatype.org/content/repositories/snapshots/org/scalameta/mtags_2.13.1/0.7.6+404-2cb4e3b0-SNAPSHOT/mtags_2.13.1-0.7.6+404-2cb4e3b0-SNAPSHOT.jar

The readme still recommends git fetch --tags in CI environments so it might be worth a mention. --unshallow is mentioned in the sanity check section.

Thank you!

[dwijnand]

👍 9d128a8