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

Base version calculation failed since 5.6.5 #2801

Closed
dotlegacy opened this issue Aug 9, 2021 · 28 comments
Closed

Base version calculation failed since 5.6.5 #2801

dotlegacy opened this issue Aug 9, 2021 · 28 comments

Comments

@dotlegacy
Copy link

There seems to be a bug that started in version 5.6.5 where it is does not utilize the existing commit tags information to determine the version. I was tested many versions from 5.6.4 and lower and it works while any version from 5.6.5 to 5.6.11 does not. I do not have a sample test repo that replicates this behavior but it is a relatively new repository with just a single version tag "0.1.0".

Log from 5.6.4:
image

Log from 5.6.5:
image

GitVersion configuration:
The below configuration is for 5.6.5; and slightly different on 5.6.4, which used the branch "master" instead of "main".
image

@asbjornu
Copy link
Member

asbjornu commented Aug 9, 2021

Sub 1.0.0 tags has always been a bit wonky in GitVersion. I believe the behaviour should be more predictable after a 1.0.0 tag.

@dotlegacy
Copy link
Author

I don't see why it would behave differently but if there are no consistent behavior with any version below 1.0.0, I would recommend disabling the ability for developers to use anything lower than 1.0.0 and have it documented.

@asbjornu
Copy link
Member

I agree it's unfortunate and we do consider it a bug, it's just not something we maintainers have an incentive to fix since we rarely add tags lower than 1.0.0. Pull requests are welcome.

@antonysmith-mando
Copy link

Sub 1.0.0 tags has always been a bit wonky in GitVersion. I believe the behaviour should be more predictable after a 1.0.0 tag.

@asbjornu I'm seeing some behaviour that suggests there may be an issue with calculating base versions since 5.6.4 - not sure if it's exactly the same as the issue reported here, but feels at least related.

Running GitVersion against a release branch (1.1.0) in my repo returns a different base version between 5.6.3 and 5.6.4. In 5.6.4, this results in a CommitsSinceVersionSource value of 0.

It looks like the difference is that, since 5.6.4, the remote of the same branch is being returned as a source branch.

5.6.3 output:

INFO [09/09/21 7:55:32:20] Working directory: C:\projects\uss-services
INFO [09/09/21 7:55:32:32] Project root is: C:\projects\uss-services\
INFO [09/09/21 7:55:32:32] DotGit directory is: C:\projects\uss-services\.git
INFO [09/09/21 7:55:32:69] Using latest commit on specified branch
INFO [09/09/21 7:55:32:76] Running against branch: release/1.1.0 (2e50b1dbc6642f9549be595a6e1c970583f2ad55)
INFO [09/09/21 7:55:32:77] Begin: Calculating base versions
  INFO [09/09/21 7:55:32:79] NextVersion in GitVersion configuration file: 0.1.0 with commit count source External Source
  INFO [09/09/21 7:55:33:01] Found commit [2e50b1dbc6642f9549be595a6e1c970583f2ad55] matching merge message format: Default
  INFO [09/09/21 7:55:33:01] Found commit [2e50b1dbc6642f9549be595a6e1c970583f2ad55] matching merge message format: Default
  INFO [09/09/21 7:55:33:01] Found commit [2e50b1dbc6642f9549be595a6e1c970583f2ad55] matching merge message format: Default
  INFO [09/09/21 7:55:33:01] Merge message 'Merge branch 'release/1.0.0' of bitbucket.org:Mando-Agency/uss-services into release/1.0.0': 1.0.0 with commit count source 9ae8b3829c48263b76b8ad39e682e0d3a5fe2d47
  INFO [09/09/21 7:55:33:01] Merge message 'Merge branch 'release/0.3.0' into develop': 0.3.0 with commit count source 89eb79d2770f422bae0ee97e3164eb2322b10820
  INFO [09/09/21 7:55:33:01] Merge message 'Merge branch 'release/0.2.0' into develop': 0.2.0 with commit count source 26655cade0acf89fc71e7358ea998555131cd26a
  INFO [09/09/21 7:55:33:06] Git tag '1.0.0': 1.0.0 with commit count source 9fcb91752a717ab5f49bd9ca6455c08ec77848d4
  INFO [09/09/21 7:55:33:06] Begin: Finding branch source of 'release/1.1.0'
    INFO [09/09/21 7:55:33:09] Begin: Finding merge base between 'release/1.1.0' and 'develop'.
      INFO [09/09/21 7:55:33:10] Found merge base of 93d60123d4d40170db82f30edf611b6e75aa59b7
      INFO [09/09/21 7:55:33:11] Merge base of release/1.1.0' and 'develop is GitVersion.Commit
    INFO [09/09/21 7:55:33:12] End: Finding merge base between 'release/1.1.0' and 'develop'. (Took: 26.70ms)
    INFO [09/09/21 7:55:33:12] Begin: Finding merge base between 'release/1.1.0' and 'master'.
      INFO [09/09/21 7:55:33:14] Found merge base of 9fcb91752a717ab5f49bd9ca6455c08ec77848d4
      INFO [09/09/21 7:55:33:14] Merge base of release/1.1.0' and 'master is GitVersion.Commit
    INFO [09/09/21 7:55:33:14] End: Finding merge base between 'release/1.1.0' and 'master'. (Took: 14.42ms)
    INFO [09/09/21 7:55:33:14] Begin: Finding merge base between 'release/1.1.0' and 'release/1.1.0'.
      INFO [09/09/21 7:55:33:14] Found merge base of 2e50b1dbc6642f9549be595a6e1c970583f2ad55
      INFO [09/09/21 7:55:33:14] Merge base of release/1.1.0' and 'release/1.1.0 is GitVersion.Commit
    INFO [09/09/21 7:55:33:14] End: Finding merge base between 'release/1.1.0' and 'release/1.1.0'. (Took: 2.62ms)
    INFO [09/09/21 7:55:33:14] Begin: Finding merge base between 'release/1.1.0' and 'origin/release/1.1.0'.
      INFO [09/09/21 7:55:33:14] Found merge base of 2e50b1dbc6642f9549be595a6e1c970583f2ad55
      INFO [09/09/21 7:55:33:14] Merge base of release/1.1.0' and 'origin/release/1.1.0 is GitVersion.Commit
    INFO [09/09/21 7:55:33:14] End: Finding merge base between 'release/1.1.0' and 'origin/release/1.1.0'. (Took: 2.52ms)
    INFO [09/09/21 7:55:33:15] Multiple source branches have been found, picking the first one (develop).
This may result in incorrect commit counting.
Options were:
develop, master
  INFO [09/09/21 7:55:33:15] End: Finding branch source of 'release/1.1.0' (Took: 84.69ms)
  INFO [09/09/21 7:55:33:15] Version in branch name: 1.1.0 with commit count source 93d60123d4d40170db82f30edf611b6e75aa59b7
  INFO [09/09/21 7:55:33:16] Found multiple base versions which will produce the same SemVer (1.1.0), taking oldest source for commit counting (Version in branch name)
  INFO [09/09/21 7:55:33:16] Base version used: Version in branch name: 1.1.0 with commit count source 93d60123d4d40170db82f30edf611b6e75aa59b7
  INFO [09/09/21 7:55:33:16] End: Calculating base versions (Took: 397.16ms)
  INFO [09/09/21 7:55:33:16] Skipping version increment
  INFO [09/09/21 7:55:33:17] 19 commits found between 93d60123d4d40170db82f30edf611b6e75aa59b7 and 2e50b1dbc6642f9549be595a6e1c970583f2ad55
  INFO [09/09/21 7:55:33:17] Begin: Getting version tags from branch 'refs/heads/release/1.1.0'.
  INFO [09/09/21 7:55:33:33] End: Getting version tags from branch 'refs/heads/release/1.1.0'. (Took: 158.68ms)
  INFO [09/09/21 7:55:33:37] Done writing 

5.6.4 output:

INFO [09/09/21 7:55:17:28] Working directory: C:\projects\uss-services
INFO [09/09/21 7:55:17:40] Project root is: C:\projects\uss-services\
INFO [09/09/21 7:55:17:40] DotGit directory is: C:\projects\uss-services\.git
INFO [09/09/21 7:55:17:67] Using latest commit on specified branch
INFO [09/09/21 7:55:17:74] Running against branch: release/1.1.0 (2e50b1d adding updated version of config files...  previous versions seemed to error when deployed)
INFO [09/09/21 7:55:17:75] Begin: Calculating base versions
  INFO [09/09/21 7:55:17:77] NextVersion in GitVersion configuration file: 0.1.0 with commit count source External Source
  INFO [09/09/21 7:55:17:84] Fallback base version: 0.1.0 with commit count source 87d5e1a71f6573c05b7a9032df9a5a91656ab070
  INFO [09/09/21 7:55:18:04] Found commit [2e50b1d adding updated version of config files...  previous versions seemed to error when deployed] matching merge message format: Default
  INFO [09/09/21 7:55:18:04] Found commit [2e50b1d adding updated version of config files...  previous versions seemed to error when deployed] matching merge message format: Default
  INFO [09/09/21 7:55:18:04] Found commit [2e50b1d adding updated version of config files...  previous versions seemed to error when deployed] matching merge message format: Default
  INFO [09/09/21 7:55:18:04] Merge message 'Merge branch 'release/1.0.0' of bitbucket.org:Mando-Agency/uss-services into release/1.0.0': 1.0.0 with commit count source 9ae8b3829c48263b76b8ad39e682e0d3a5fe2d47
  INFO [09/09/21 7:55:18:04] Merge message 'Merge branch 'release/0.3.0' into develop': 0.3.0 with commit count source 89eb79d2770f422bae0ee97e3164eb2322b10820
  INFO [09/09/21 7:55:18:04] Merge message 'Merge branch 'release/0.2.0' into develop': 0.2.0 with commit count source 26655cade0acf89fc71e7358ea998555131cd26a
  INFO [09/09/21 7:55:18:10] Git tag '1.0.0': 1.0.0 with commit count source 9fcb91752a717ab5f49bd9ca6455c08ec77848d4
  INFO [09/09/21 7:55:18:10] Begin: Finding branch source of 'release/1.1.0'
    INFO [09/09/21 7:55:18:12] Begin: Finding merge base between 'release/1.1.0' and 'develop'.
      INFO [09/09/21 7:55:18:14] Found merge base of 93d6012 Merged in feature/run-function-on-ci (pull request #39)
      INFO [09/09/21 7:55:18:15] Merge base of release/1.1.0' and 'develop is 93d6012 Merged in feature/run-function-on-ci (pull request #39)
    INFO [09/09/21 7:55:18:16] End: Finding merge base between 'release/1.1.0' and 'develop'. (Took: 24.64ms)
    INFO [09/09/21 7:55:18:16] Begin: Finding merge base between 'release/1.1.0' and 'master'.
      INFO [09/09/21 7:55:18:17] Found merge base of 9fcb917 small logging setting change.  set these through octopus instead
      INFO [09/09/21 7:55:18:17] Merge base of release/1.1.0' and 'master is 9fcb917 small logging setting change.  set these through octopus instead
    INFO [09/09/21 7:55:18:17] End: Finding merge base between 'release/1.1.0' and 'master'. (Took: 15.06ms)
    INFO [09/09/21 7:55:18:18] Begin: Finding merge base between 'release/1.1.0' and 'origin/release/1.1.0'.
      INFO [09/09/21 7:55:18:18] Found merge base of 2e50b1d adding updated version of config files...  previous versions seemed to error when deployed
      INFO [09/09/21 7:55:18:18] Merge base of release/1.1.0' and 'origin/release/1.1.0 is 2e50b1d adding updated version of config files...  previous versions seemed to error when deployed
    INFO [09/09/21 7:55:18:18] End: Finding merge base between 'release/1.1.0' and 'origin/release/1.1.0'. (Took: 2.69ms)
    INFO [09/09/21 7:55:18:18] Multiple source branches have been found, picking the first one (origin/release/1.1.0).
This may result in incorrect commit counting.
Options were:
origin/release/1.1.0, develop, master
  INFO [09/09/21 7:55:18:18] End: Finding branch source of 'release/1.1.0' (Took: 84.11ms)
  INFO [09/09/21 7:55:18:18] Version in branch name: 1.1.0 with commit count source 2e50b1dbc6642f9549be595a6e1c970583f2ad55
  INFO [09/09/21 7:55:18:26] Found multiple base versions which will produce the same SemVer (1.1.0), taking oldest source for commit counting (Version in branch name)
  INFO [09/09/21 7:55:18:26] Base version used: Version in branch name: 1.1.0 with commit count source 2e50b1dbc6642f9549be595a6e1c970583f2ad55
  INFO [09/09/21 7:55:18:26] End: Calculating base versions (Took: 514.59ms)
  INFO [09/09/21 7:55:18:26] Skipping version increment
  INFO [09/09/21 7:55:18:27] 0 commits found between 2e50b1d adding updated version of config files...  previous versions seemed to error when deployed and 2e50b1d adding updated version of config files...  previous versions seemed to error when deployed
  INFO [09/09/21 7:55:18:27] Begin: Getting version tags from branch 'refs/heads/release/1.1.0'.
  INFO [09/09/21 7:55:18:33] End: Getting version tags from branch 'refs/heads/release/1.1.0'. (Took: 60.33ms)
  INFO [09/09/21 7:55:18:37] Done writing 

Is this expected behaviour? Or is there a possible issue with my repo/config that is causing this?

FYI, GitVersion.yml is:

next-version: 0.1
branches:  
  develop:
    tag: unstable
  release:
    regex: releases?[/-]
    mode: ContinuousDeployment
  feature:
    regex: features?[/-]
    mode: ContinuousDeployment
  hotfix:
    regex: hotfix(es)?[/-]
    mode: ContinuousDeployment
ignore:
  sha: []

Thanks.

@asbjornu
Copy link
Member

Is the output from 5.7.0 the same as from 5.6.4?

@antonysmith-mando
Copy link

antonysmith-mando commented Sep 21, 2021

@asbjornu I did wonder whether it was an issue that had been fixed in 5.7.0, but yes, it's still the same. Output below:

INFO [09/21/21 7:23:02:52] Working directory: C:\projects\uss-services
INFO [09/21/21 7:23:02:62] Project root is: C:\projects\uss-services\
INFO [09/21/21 7:23:02:62] DotGit directory is: C:\projects\uss-services\.git
INFO [09/21/21 7:23:02:89] Using latest commit on specified branch
INFO [09/21/21 7:23:03:04] Running against branch: release/1.1.0 (6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45))
INFO [09/21/21 7:23:03:04] Begin: Calculating base versions
  INFO [09/21/21 7:23:03:06] NextVersion in GitVersion configuration file: 0.1.0 with commit count source External Source
  INFO [09/21/21 7:23:03:12] Fallback base version: 0.1.0 with commit count source 87d5e1a71f6573c05b7a9032df9a5a91656ab070
  INFO [09/21/21 7:23:03:21] Found commit [6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45)] matching merge message format: Default
  INFO [09/21/21 7:23:03:21] Found commit [6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45)] matching merge message format: Default
  INFO [09/21/21 7:23:03:21] Found commit [6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45)] matching merge message format: Default
  INFO [09/21/21 7:23:03:22] Merge message 'Merge branch 'release/1.0.0' of bitbucket.org:Mando-Agency/uss-services into release/1.0.0': 1.0.0 with commit count source 9ae8b3829c48263b76b8ad39e682e0d3a5fe2d47
  INFO [09/21/21 7:23:03:22] Merge message 'Merge branch 'release/0.3.0' into develop': 0.3.0 with commit count source 89eb79d2770f422bae0ee97e3164eb2322b10820
  INFO [09/21/21 7:23:03:22] Merge message 'Merge branch 'release/0.2.0' into develop': 0.2.0 with commit count source 26655cade0acf89fc71e7358ea998555131cd26a
  INFO [09/21/21 7:23:03:26] Git tag '1.0.0': 1.0.0 with commit count source 9fcb91752a717ab5f49bd9ca6455c08ec77848d4
  INFO [09/21/21 7:23:03:27] Begin: Finding branch source of 'release/1.1.0'
    INFO [09/21/21 7:23:03:28] Begin: Finding merge base between 'release/1.1.0' and 'develop'.
      INFO [09/21/21 7:23:03:30] Found merge base of 93d6012 Merged in feature/run-function-on-ci (pull request #39)
      INFO [09/21/21 7:23:03:31] Merge base of release/1.1.0' and 'develop is 93d6012 Merged in feature/run-function-on-ci (pull request #39)
    INFO [09/21/21 7:23:03:32] End: Finding merge base between 'release/1.1.0' and 'develop'. (Took: 27.02ms)
    INFO [09/21/21 7:23:03:32] Begin: Finding merge base between 'release/1.1.0' and 'master'.
      INFO [09/21/21 7:23:03:33] Found merge base of 9fcb917 small logging setting change.  set these through octopus instead
      INFO [09/21/21 7:23:03:33] Merge base of release/1.1.0' and 'master is 9fcb917 small logging setting change.  set these through octopus instead
    INFO [09/21/21 7:23:03:33] End: Finding merge base between 'release/1.1.0' and 'master'. (Took: 13.17ms)
    INFO [09/21/21 7:23:03:34] Begin: Finding merge base between 'release/1.1.0' and 'origin/release/1.1.0'.
      INFO [09/21/21 7:23:03:34] Found merge base of 6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45)
      INFO [09/21/21 7:23:03:34] Merge base of release/1.1.0' and 'origin/release/1.1.0 is 6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45)
    INFO [09/21/21 7:23:03:34] End: Finding merge base between 'release/1.1.0' and 'origin/release/1.1.0'. (Took: 1.99ms)
    INFO [09/21/21 7:23:03:34] Multiple source branches have been found, picking the first one (origin/release/1.1.0).
This may result in incorrect commit counting.
Options were:
origin/release/1.1.0, develop, master
  INFO [09/21/21 7:23:03:34] End: Finding branch source of 'release/1.1.0' (Took: 78.70ms)
  INFO [09/21/21 7:23:03:34] Version in branch name: 1.1.0 with commit count source 6f28192072815931de8f792e37b25795a936af71
  INFO [09/21/21 7:23:03:41] Found multiple base versions which will produce the same SemVer (1.1.0), taking oldest source for commit counting (Version in branch name)
  INFO [09/21/21 7:23:03:41] Base version used: Version in branch name: 1.1.0 with commit count source 6f28192072815931de8f792e37b25795a936af71
  INFO [09/21/21 7:23:03:41] End: Calculating base versions (Took: 375.34ms)
  INFO [09/21/21 7:23:03:42] 0 commits found between 6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45) and 6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45)
  INFO [09/21/21 7:23:03:42] Skipping version increment
  INFO [09/21/21 7:23:03:42] 0 commits found between 6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45) and 6f28192 Merged in feature/USSBENCON-179-further-modelling-validation (pull request #45)
  INFO [09/21/21 7:23:03:42] Begin: Getting version tags from branch 'refs/heads/release/1.1.0'.
  INFO [09/21/21 7:23:03:47] End: Getting version tags from branch 'refs/heads/release/1.1.0'. (Took: 46.46ms)
  INFO [09/21/21 7:23:03:50] Done writing 

@asbjornu
Copy link
Member

The important difference seems to be these two differing lines:

Multiple source branches have been found, picking the first one (develop).

Multiple source branches have been found, picking the first one (origin/release/1.1.0).

So I can only assume that something has changed between 5.6.3 and 5.6.4 regarding ordering of branches that makes it chose release/1.1.0 over develop.

However, as the log indicates, "incorrect commit counting" may occur due to GitVersion finding several source branches, so I would say your repository is in undefined territory and that unexpected change of behaviour is to be expected.

I would investigate why multiple source branches are found and fix that problem, if I were you.

@antonysmith-mando
Copy link

What I thought was more interesting was that origin/release/1.1.0 was not even returned as a source branch prior to 5.6.4. It seems to be the sources that are being returned that is the problem, rather than the ordering of them.

This issue seems to suggest that the same issue had existed previously.

I understand that multiple source branches can cause issues with commit counting but, without this branch being returned as a source branch - which the above issue suggests was/is incorrect - the issue wouldn't exist.

@antonysmith-mando
Copy link

I've built the source locally and had a look. Looks like the issue is that the way that branches are being compared has changed. In the 5.6.3 version of RepositoryMetadataProvider's FindCommitBranchWasBranchedFrom method, the remote branch was actually being returned from GetMergeCommitsForBranch but was being filtered out in the where clause following a call to IsSameBranch, which did an equivalence check on both branches using the NameWithoutRemote method.

In 5.6.4, this call to IsSameBranch has been replaced with a call to .Equals() which is returning false.

@antonysmith-mando
Copy link

Updating line 324 of RepositoryStore.cs from:

.Where(b => !branch.Equals(b.Branch))

To:

.Where(b => !branch.Name.EquivalentTo(b.Branch.Name.WithoutRemote))

Looks to be more in keeping with how the functionality worked prior to 5.6.4, resolves my issue and also keeps all existing tests passing. Happy to raise a PR if you think this seems like a reasonable change?

@asbjornu
Copy link
Member

Sounds great! A PR would be welcome. 🙏🏼

@ajsmith27
Copy link
Contributor

@asbjornu PR raised. It's the first OS PR I've raised so please do let me know if I've not done anything properly. Cheers

@LordMike
Copy link

LordMike commented Jan 14, 2022

Ohai - I just found out that upgrading from 5.0 beta to 5.8.1 yielded something that looks like this. Our tags are no longer used, and Gitversion goes back to a (very) old release branch when we used that.

I tried gitversion 6.5.4, and got our expected version 1.11.0-alphaXXX, while 6.5.5 and 6.8.1 both give a wrong 1.6.0-alphaXXX (our last release branch was 1.5.0).

I couldn't identify if the merged PR was in 5.8.1 ? .. Its milestone is 5.8.0, so I think it would be in?
If so, it's likely still a bug. :|

@antonysmith-mando
Copy link

antonysmith-mando commented Jan 14, 2022

The code change I made is present in the 5.8.1 tag: https://github.com/GitTools/GitVersion/blob/5.8.1/src/GitVersion.Core/Core/RepositoryStore.cs

This change definitely resolved my issue... may be that your issue has a slightly different route cause to the issue that my change addressed? It should also be noted that the issue I addressed may not be the same as the one in the original issue raised here (I did note that it may not be the same, but felt at least related). Therefore if your behaviour is more in line with the issue originally raised, then it may also be that my change hasn't resolved your issue

@LordMike
Copy link

I've tried to create a reproduce that doesn't require disclosing our entire history, but after a few hours I haven't been able to.. I boil down the history and replace messages, but I can't get both the 5.6.4 and later versions of gitversion to give the output I currently see in our original repository.

If needed, I can give it another shot, and maybe send a bundle to @asbjornu or another dev for testing. As a minimum, I can remove the data, the authors, and maybe most messages (if I can figure out the exact messages needed for base calculation)..

@asbjornu
Copy link
Member

@LordMike, thanks for spending so much time trying to reproduce this. That is highly appreciated! The best for future proofing against this bug would be to have a RepositoryFixture that reproduces the bug in a test. The next best thing would be to have a public repository that we can exercise some integration tests against. If both of those options are hard or impossible, you're free to send me a failing repository privately on Keybase.

@LordMike
Copy link

LordMike commented Jan 17, 2022

I think I know more about why I had such issues reproducing.. I've just found that apparently the cache gitversion makes, is giving me issues?.. So making a version with one gitversion, makes a different gitversion produce the same results even when it shouldn't.. I'm running with -nocache now to combat this.

... This helped a lot. I have the following.

In this repository, we got 1.8.x with gitversion 5.8.1, but 1.11.x with gitversion 5.6.4. I expect the latter, as there is a v1.10.x tag on the master branch, which should mean that the develop branch is one minor ahead (given our, simple, config).

# My script to create this bundle / repo
# Setup
git clone URL.git

	# Remove content
	../git-filter-repo --prune-empty never --path GitVersion.yml

	# Remove authors
	../git-filter-repo --name-callback 'return b"LordMike"' --email-callback 'return b"michael@mbwarez.dk"'

	# Remove branches & tags
	git branch | grep -vF master | grep -vF develop | xargs git branch -D
	git tag | grep -vF v1.7 | grep -vF v1.8 | grep -vF v1.9 | grep -vF v1.10 | xargs git tag -d

	# Truncate messages
	../git-filter-repo --message-callback 'return message if b"Merge" in message else b"Truncated"'

# With broken 5.8.1
dotnet tool uninstall --global GitVersion.Tool; dotnet tool install --global GitVersion.Tool --version 5.8.1
dotnet-gitversion -nocache

	Produces:
	1.8.0-alpha**

# With fixed 5.6.4
dotnet tool uninstall --global GitVersion.Tool; dotnet tool install --global GitVersion.Tool --version 5.6.4
dotnet-gitversion -nocache

	Produces (as expected):
	1.11.0-alpha**

I've created a bundle that you can clone from (git clone issue-2801.bundle)
issue-2801.zip

Running the two dotnet-install / dotnet-gitversion commands should produce the 1.8.x and 1.11.x outputs respectively.

@LordMike
Copy link

If we can figure out which commits are needed, I can try making a unit test with the necessary commits/tags/branches to reproduce this.

Some other weird stuff I noticed. I originally removed more tags than I leave in this bundle, but doing so pushed the gitversion further back to 1.6.x, which I also found odd, given that I left the v1.7.x tags in place. Removing the v1.7 tags produces 1.6.x versions.

Gitversion 5.6.4 still produces the correct 1.11.x versions even without these tags. It simply picks up a different, newer, source.

@asbjornu
Copy link
Member

GitVersion should choose the highest version source it finds and shouldn't care about when they were added. If that's something that changed after version 5.6.4, we need to look into the code doing the ordering. Are you able to pull down GitVersion's source and do a git bisect to find exactly which commit is to blame for this change of behaviour, @LordMike?

@LordMike
Copy link

I might be - will see if I can fit it in.. :)

@LordMike
Copy link

LordMike commented Mar 2, 2022

@asbjornu I tried git bisect for the first time, to see what that does.. Neat command :)

So I ran the src\GitVersion.App and src\GitVersionExe applications (they were renamed between 5.6.4 and 5.6.5) with dotnet run -f netcoreapp3.1 -- N:\Git\MyProject\ -nocache and noted the version that came out. In 5.6.4, at time of writing, I get version 1.12.0-alpha***, while 5.6.5 gives me 1.11.0-alpha***. We just released 1.11, so 1.12 is correct for our working branch, develop.

The following commit is marked as "bad": 8b653e9

> git bisect bad
8b653e9f75cae9c9918a148de23864feaae736f1 is the first bad commit
commit 8b653e9f75cae9c9918a148de23864feaae736f1
Author: Artur <arturcic@gmail.com>
Date:   Sun Jan 31 12:14:26 2021 +0100

    changed the default branch from master to main

 README.md                                            | 14 +++++++-------
 .../Fixtures/RepositoryFixtureBase.cs                |  2 +-
 ...ts.CanWriteOutEffectiveConfiguration.approved.txt | 12 ++++++------
 src/GitVersion.Core.Tests/Helpers/TestBase.cs        |  2 +-
 .../IntegrationTests/OtherScenarios.cs               |  6 +++---
 .../Configuration/ConfigFileLocator.cs               |  2 +-
 .../Configuration/ConfigurationBuilder.cs            | 20 +++++++++++---------
 src/GitVersion.Core/Model/Configuration/Config.cs    |  2 +-
 8 files changed, 31 insertions(+), 29 deletions(-)

It sounds like it could be obvious - we use master as our release branch. If I run -showconfig in this commit, I get the following for the main branch:

  main:
    mode: ContinuousDeployment
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^master$|^main$
    source-branches:
    - develop
    - release
    tracks-release-branches: false
    is-release-branch: false
    is-mainline: true
    pre-release-weight: 55000

While in 5.6.4, I get the following for master:

  master:
    mode: ContinuousDeployment
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^master$|^main$
    source-branches:
    - develop
    - release
    tracks-release-branches: false
    is-release-branch: false
    is-mainline: true
    pre-release-weight: 55000

Maybe some code has a hard dependency on the name master... Hmm.

@LordMike
Copy link

LordMike commented Mar 2, 2022

So, I tried copying the config of the working 5.6.4 release into our GitVersion.yml file, and ran that. 5.6.5 shows the following error:

> dotnet run -f netcoreapp3.1 -- N:\Git\MyProject\ -nocache
INFO [03/02/22 22:42:57:39] Working directory: N:\Git\MyProject
INFO [03/02/22 22:42:57:44] Project root is: N:\Git\MyProject\
INFO [03/02/22 22:42:57:44] DotGit directory is: N:\Git\MyProject\.git
ERROR [03/02/22 22:42:57:60] An unexpected error occurred:
GitVersion.Configuration.ConfigurationException: Branch configuration 'release' defines these 'source-branches' that are not configured: '[master]'

Which is weird, because my config specifically configures master. If I fix the immediate errors, my master branch configuration has been dropped in favour of a new main configuration.

... but it should still work imo, as the name of the configuration shouldn't matter - the regex that identifies the branch names is the same.

Soo.. I'm at a loss.. :)

@asbjornu
Copy link
Member

asbjornu commented Mar 2, 2022

I wonder if this is related to #2590. 🤔

@LordMike
Copy link

LordMike commented Mar 3, 2022

Sounds identical. :O

@LordMike
Copy link

@asbjornu I can see that #2590 was resolved in 5.10.0 .. this is fixed too then? :)

@asbjornu
Copy link
Member

I should think so, @LordMike! Can you please take it for a spin and report back your findings? 🙏🏼

@LordMike
Copy link

LordMike commented May 12, 2022 via email

@asbjornu
Copy link
Member

Resolved in #3037.

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

No branches or pull requests

5 participants