Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System.OverflowException for ParseInt32[Bug] #2390

Closed
OatmealOgre opened this issue Aug 21, 2020 · 7 comments · Fixed by #3028
Closed

System.OverflowException for ParseInt32[Bug] #2390

OatmealOgre opened this issue Aug 21, 2020 · 7 comments · Fixed by #3028
Labels
Milestone

Comments

@OatmealOgre
Copy link

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
Copy link
Member

A pull request fixing this would be warmly welcomed!

@quasarea
Copy link

quasarea commented Feb 3, 2021

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
Copy link
Member

asbjornu commented Feb 3, 2021

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

@quasarea
Copy link

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
Copy link

james-bjss commented May 24, 2021

@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
Copy link
Member

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

@asbjornu asbjornu mentioned this issue Mar 3, 2022
5 tasks
@asbjornu asbjornu added this to the 5.x milestone Mar 3, 2022
@arturcic arturcic modified the milestones: 5.x, 5.8.3 Mar 5, 2022
@github-actions
Copy link

github-actions bot commented Mar 5, 2022

🎉 This issue has been resolved in version 5.8.3 🎉
The release is available on:

Your GitReleaseManager bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants