We are getting the following error when trying to publish our package after successfully building it.
/usr/share/dotnet/sdk/8.0.204/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.GenerateAssemblyInfo.targets(226,5): error NETSDK1018: Invalid NuGet version string: '1.0.0-06181390'. [/app_build/OurProject/OurSolution/OurSolution.csproj]
1.0.0-06181390 is our version which we are giving using /p:Version=$VERSION variable while building it and publishing it through GitLab pipeline. Basically, we are using the CI_COMMIT_SHORT_SHA at the end of the version, like 1.0.0-$CI_COMMIT_SHORT_SHA.
It was working fine until a couple of days ago, but now we are getting this. Any help on understanding why the sudden change might have occurred?
You currently use the commit hash as a pre-release indicator. According to the official SemVer documentation
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers [...]. Numeric [pre-release] identifiers MUST NOT include leading zeroes.
The reason this has worked so far is that only a small amount of commit hashes (about 6%) start with a leading zero, and an even smaller amount (about 2% for shortened hashes) contain only numbers (no hexadecimal digits a-f). You basically just got very unlucky with your commit hash, hitting a chance of about 0.15%.
This means you have three basic options:
Decrease the likelihood of having no letters in the commit hash, by using the full 40 character commit hash CI_COMMIT_SHA instead of the shortened one. This reduces the probability of an invalid version to about 4 * 10-10 or about 1 in 2 billion.
Make your pre-release identifier non-numeric. Add some kind of identifier before or after your commit hash. It can even be separated by a hyphen, e.g. 1.0.0-sha-06181390 or 1.0.0-06181390-git
Actually use correct semantic versioning. According to SemVer
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version.
So your version should actually look like this: 1.0.0+06181390
I would strongly suggest using the third option, as this is the only one that uses correct versioning.