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

[Bug] Version of commit in develop merged to master changes if master is tagged #3105

Closed
mycroes opened this issue May 2, 2022 · 8 comments · Fixed by #3190
Closed

[Bug] Version of commit in develop merged to master changes if master is tagged #3105

mycroes opened this issue May 2, 2022 · 8 comments · Fixed by #3190
Labels
Milestone

Comments

@mycroes
Copy link

mycroes commented May 2, 2022

Describe the bug
In a repository where commit A from develop is merged into master as commit B, GitVersion generates a different version for commit A if B is tagged with a version.

Expected Behavior

GitVersion produces version (5.1.0-alpha.15+Branch.develop.Sha.ffaca48e8c7bf98e28bccbec0ee8816178f78470) based on history of commit A in develop, as it does when B is not tagged.

Actual Behavior

GitVersion produces version (6.1.0-alpha.0+Branch.develop.Sha.ffaca48e8c7bf98e28bccbec0ee8816178f78470) based on the 'future' merge of A into master as commit B with tag v6.0.0

Possible Fix

Ignore all commits derived from current commit in version calculation.

Steps to Reproduce

  1. Create commit A on develop
  2. Run GitVersion, take note of version generated
  3. Merge commit A into master, generating commit B
  4. Tag commit B with next release version
  5. Checkout develop (still pointing to commit A)
  6. Run GitVersion, take note of version generated

Context

Affects builds that deploy packages when the package deployment is ran after the merge commit has also been tagged. We deploy packages using Jenkins on merge in Gerrit, so there's a fair chance of this happening on the last commits before release.

Your Environment

  • Version Used: 5.10.1
  • Windows 10
@mycroes mycroes added the bug label May 2, 2022
@asbjornu
Copy link
Member

Different commits on different branches produce different version numbers. That's sort of the entire point of GitVersion. I don't see the problem here?

@mycroes
Copy link
Author

mycroes commented Aug 26, 2022

The same commit on the same branch produces a different version number (after a new commit is added), that seems pretty awkward to me.

@asbjornu
Copy link
Member

What you are seeing is GitVersion working as it should. develop should always produce a higher version number than main or master. This is by design.

@mycroes
Copy link
Author

mycroes commented Aug 26, 2022

Please carefully read the original issue. I fully understand what you're saying, that's not the issue I'm having. Thanks for looking into this!

@asbjornu
Copy link
Member

Can you please create a RepositoryFixture test that performs all the necessary steps as well as the version number assertions you expect along the way?

@HHobeck
Copy link
Contributor

HHobeck commented Sep 21, 2022

    [Test]
    public void __Just_A_Test__()
    {
        using EmptyRepositoryFixture fixture = new("develop");

        var configBuilder = ConfigBuilder.New;

        // Create commit A on develop
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.1.0-alpha.1", configBuilder.Build());

        // Branch develop to main
        fixture.BranchTo("main");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.1+1", configBuilder.Build());

        // Create commit B on main
        fixture.MakeACommit();

        // ✅ succeeds as expected
        fixture.AssertFullSemver("0.0.1+2", configBuilder.Build());

        // Tag commit B with next release version
        fixture.ApplyTag("1.0.0");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.0.0", configBuilder.Build());

        // Checkout develop (still pointing to commit A)
        fixture.Checkout("develop");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.1.0-alpha.0", configBuilder.Build());

        // Merge changes from main to develop
        fixture.MergeNoFF("main");

        // ✅ succeeds as expected
        fixture.AssertFullSemver("1.1.0-alpha.1", configBuilder.Build());
    }

Actually this is maybe fixed in the PR #3190 . Are you agree?

@mycroes
Copy link
Author

mycroes commented Sep 21, 2022

Thx @HHobeck, I'm short on time and didn't know it would be this easy to write a test for it. This shows exactly what I meant, good work.

Edit: not sure if PR fixes this, but the test matches

@asbjornu asbjornu added this to the 6.x milestone Oct 11, 2022
@arturcic arturcic modified the milestones: 6.x, 6.0.0-alpha.1 Dec 22, 2022
@arturcic
Copy link
Member

🎉 This issue has been resolved in version 6.0.0 🎉
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
4 participants