System.OverflowException for ParseInt32[Bug]

[OatmealOgre]

Describe the bug
When gitversion tries to parse a prerelease tag followed by a 10+ digit number an exception is thrown.

Expected Behavior

Gitversion should catch the exception and handle it some other way

Actual Behavior

Gitversion doesn't handle any exceptions inside a method called TryParse

Possible Fix

Make TryParse method of GitVersionCore/VersionCalculation/SemanticVersioning/SemanticVersion.cs actually use a try-catch as the name would suggest.
Alternatively have GitVersionCore/VersionCalculation/SemanticVersioning/SemanticVersionPreReleaseTag.cs Parse method use a TryParse for parsing the Int

Steps to Reproduce

Use a tag with a long number in it. Ours has been automated.
Here's the exception along with the tag that likely caused the issue:

System.OverflowException: Value was either too large or too small for an Int32.
   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   at GitVersion.SemanticVersionPreReleaseTag.Parse(String preReleaseTag)
   at GitVersion.SemanticVersion.TryParse(String version, String tagPrefixRegex, SemanticVersion& semanticVersion)
   at GitVersion.GitRepoMetadataProvider.GetValidVersionTags(IRepository repository, String tagPrefixRegex, Nullable`1 olderThan)
   at GitVersion.VersionCalculation.BaseVersionCalculators.TaggedCommitVersionStrategy.GetTaggedVersions(GitVersionContext context, Branch currentBranch, Nullable`1 olderThan)
   at GitVersion.VersionCalculation.BaseVersionCalculators.TaggedCommitVersionStrategy.GetVersions(GitVersionContext context)
   at System.Linq.Enumerable.<SelectManyIterator>d__17`2.MoveNext()
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at GitVersion.VersionCalculation.BaseVersionCalculator.GetBaseVersion(GitVersionContext context)
   at GitVersion.VersionCalculation.NextVersionCalculator.FindVersion(GitVersionContext context)
   at GitVersion.GitVersionFinder.FindVersion(GitVersionContext context)
   at GitVersion.ExecuteCore.<>c__DisplayClass7_0.<ExecuteInternal>b__0(IRepository repo)
   at GitVersion.GitPreparer.WithRepository[TResult](Func`2 action)
   at GitVersion.ExecuteCore.ExecuteGitVersion(String targetUrl, String dynamicRepositoryLocation, Authentication authentication, String targetBranch, Boolean noFetch, String workingDirectory, String commitId, Config overrideConfig, Boolean noCache)
   at GitVersion.SpecifiedArgumentRunner.Run(Arguments arguments, IFileSystem fileSystem)
   at GitVersion.Program.VerifyArgumentsAndRun()
  INFO [08/21/20 7:08:34:93] 
  INFO [08/21/20 7:08:34:93] Attempting to show the current git graph (please include in issue): 
  INFO [08/21/20 7:08:34:93] Showing max of 100 commits
  INFO [08/21/20 7:08:34:99] *   a401875 18 hours ago  (HEAD -> pull/22012/merge, pull/22012/merge)
|\  
| * 38895d1 18 hours ago  (origin/573637-fix-gitversion-issue, 573637-fix-gitversion-issue)
| * be84a2e 20 hours ago 
|/  
| *   5a4a29d 21 hours ago  (tag: 5.2.14, origin/release, release)
| |\  
| |/  
|/|   
| | *   513ba3f 4 days ago  (tag: 5.2.14-PullRequest2189021890, tag: 5.2.14-PullRequest21890.5)
| | |\ 

Context

Our CI build pipeline fails and we are unable to rebuild

Your Environment

Azure DevOps Task. Gitversion is 5.01 there, however this issue is also present in more recent versions.

[asbjornu]

A pull request fixing this would be warmly welcomed!

[quasarea]

replicated error, there should be some safeguard when numbers in tag overflow integer, or perhaps the tag should be excluded as does not meet version tag criteria

[asbjornu]

@quasarea, sounds like you're on to something here. Are you able to reproduce the error in a test in a pull request?

[quasarea]

sure, I missed out condition in my pipeline and each commit now gets tagged with semver at the end of pipeline.

during first build the tag 5.2.14 was found on main branch, gitversion came up with 5.2.14-PullRequest21890.5 and pipeline added this as a tag

during next build the tag 5.2.14-PullRequest21890.5 was found, gitversion came up with 5.2.14-PullRequest2189021890 and pipeline added this as a tag

during next build the tag 5.2.14-PullRequest2189021890 was found and calculation of new version thrown int overflow

[james-bjss]

@quasarea @asbjornu - I hit this issue last week. We are moving over to gitversion, but the existing build process tagged branches with a timestamp value. To work around this we either add the tag-prefix config or remove those tags on the locally checked out repo before running gitversion.

I created a PR for your first suggestion (add a try catch around the SemVer creation to catch overflow/formatting errors)
This prints a log message to STDERR not sure if this is acceptable?

If this seems sensible happy to add tests and tidy up as per feedback.

Testing

Created a local repo with a dummy commit.
Tagged with: 1.0.0-develop-20201007113711
Made a second commit tagged 1.1.1
Ran gitversion

Output

Failed to Parse Tag:
Value was either too large or too small for an Int32.
{
  "Major": 1,
  "Minor": 1,
  "Patch": 2,
  "PreReleaseTag": "",
  "PreReleaseTagWithDash": "",
  "PreReleaseLabel": "",
  "PreReleaseLabelWithDash": "",
  "PreReleaseNumber": null,
  "WeightedPreReleaseNumber": 60000,
  "BuildMetaData": 2,
  "BuildMetaDataPadded": "0002",
  "FullBuildMetaData": "2.Branch.master.Sha.a160dee02a5dac856aab2953972bfd7a2ddec9c2",
  "MajorMinorPatch": "1.1.2",
  "SemVer": "1.1.2",
  "LegacySemVer": "1.1.2",
  "LegacySemVerPadded": "1.1.2",
  "AssemblySemVer": "1.1.2.0",
  "AssemblySemFileVer": "1.1.2.0",
  "FullSemVer": "1.1.2+2",
  "InformationalVersion": "1.1.2+2.Branch.master.Sha.a160dee02a5dac856aab2953972bfd7a2ddec9c2",
  "BranchName": "master",
  "EscapedBranchName": "master",
  "Sha": "a160dee02a5dac856aab2953972bfd7a2ddec9c2",
  "ShortSha": "a160dee",
  "NuGetVersionV2": "1.1.2",
  "NuGetVersion": "1.1.2",
  "NuGetPreReleaseTagV2": "",
  "NuGetPreReleaseTag": "",
  "VersionSourceSha": "a88772b7e2aaf34aa1ee9fcd5ce40ad450066d8e",
  "CommitsSinceVersionSource": 2,
  "CommitsSinceVersionSourcePadded": "0002",
  "UncommittedChanges": 0,
  "CommitDate": "2021-05-24"
}

[asbjornu]

I think we should be able to increase this to Int64 without any breakage. A pull request implementing that with tests would be welcome.