-
Notifications
You must be signed in to change notification settings - Fork 644
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
Change the logic inheriting BranchConfiguration from parent branch if the IncrementStrategy is set to Inherit #3190
Conversation
… Here is my view on it and an example how it might be better. Not all unit tests are adapted right now from me. But this tests I have touched it looks quite good... That means the unit tests might be not correct implemented and false positive (or I have a fundamental different view on generating semantic versions). Hope this finds a way to a productive version of GitVersion because I put a lot of effort to this because I want to give something back. GitVersion is great and should be refactored more in direction of clean code. Thank you very much for given this a chance.
…l like I would expected it. But at one point I'm not certain. That's related how the version should be incremented when having a different VersioningMode ContinuousDelivery, ContinuousDeployment or Mainline. I think I have misinterpreted the parameter TrackMergeTarget and should be using instead the ContinuousDeployment value instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit surprised by the number of failing tests. It clearly indicates that we at least need to postpone this change to v6. But before you rebase from support/5.x
to main
, let's discuss the current implementation and its repercussions. I don't quite understand what you are changing and why, so it's hard to reason about why so many of the tests need to change their expected behavior.
src/GitVersion.Core.Tests/IntegrationTests/JustSomeTestScenarios.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/JustSomeTestScenarios.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core/VersionCalculation/BaseVersionCalculators/VersionStrategyBase.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core/VersionCalculation/BaseVersionCalculators/VersionStrategyModule.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core/VersionCalculation/MainlineVersionCalculator.cs
Outdated
Show resolved
Hide resolved
....Core.Tests/Configuration/ConfigProviderTests.CanWriteOutEffectiveConfiguration.approved.txt
Outdated
Show resolved
Hide resolved
First of all thank you very much for taking the time. This is actually a working copy on the view I have on GitVersion and how I think it should be behave. Of course we can agree on it to make no breaking changes (or at least not so many) and set the parameters in the ConfigurationBuilder (in version 5.x) and make the breaking configuration change later in version 6.x. Sorry that I haven't done it immediately. Anyway I would like to bring the focus on the business use cases and the behavior in general. Maybe I'm wrong and didn't understand the github or gitflow workflow. Please give me your opinion about how the default behavior should be in version 6.x. The main reason why so many tests fails are:
|
…et TrackMergeTarget to true for the main branch.
…et TrackMergeTarget to true for the support branch.
…et TrackMergeTarget to true for the develop branch.
Please do have a look. In this version the previous unit tests should be not breaking anymore. |
…mmitsSinceVersionSourceShouldNotGoDownWhenMergingHotfixToDevelop test
…instances. In advance add a overload to specify the initial branch name for the empty repository. Last but not least the logic in BaseVersionCalculator has been adapted: If the maximal version has no pre-release tag defined than we want to determine just the latest previous base source which are not comming from pre-release tag.
Can you please run
Which I've noticed before and don't quite understand why is happening. @arturcic, do you have any ideas? |
…rackMergeTarget functionality.
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
src/GitVersion.Core.Tests/IntegrationTests/PreventDecrementationOfVersionsOnTheDevelopBranch.cs
Outdated
Show resolved
Hide resolved
…sion strategy implementation is highly recursive and works with inheritance from one branch configuration to another. This makes it highly configurable and we can support every workflow on the world and all workflows which are created in the future. Please notice the BranchConfigurationCalculator is not really used anymore.
I got following error:
|
Try the following, @HHobeck: dotnet format ./src/ --exclude **/AddFormats/ The test
Is that intentional with this change? |
…tag will be present only on fallback branch configuration settings.
…into feature/3101
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff. 👏🏼 Very close now! 😃 👍🏼
...ersion.Core.Tests/VersionCalculation/Strategies/ConfigNextVersionBaseVersionStrategyTests.cs
Show resolved
Hide resolved
The refactoring step to rename the Config to Configuration class is quite huge. I would propose to do this in a separate PullRequest. But in this PR I have changed the FullConfiguration property and named it to Configuration. |
Yes, agreed.
Perfect! 👌🏼 |
Co-authored-by: Asbjørn Ulsberg <asbjorn@ulsberg.no>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Magnificent! 👏🏼
Thank you @HHobeck for your contribution! |
@asbjornu please include all the fixed bugs/ issues and this PR to the V6 milestone so that we get them included in the release notes |
@asbjornu On top of the current main branch I would do the renaming of BranchConfig -> BranchConfiguration and Config -> Configuration and create a PR. Is it okay with you? |
Please review the following PR: #3226 |
|
🎉 This issue has been resolved in version 6.0.0 🎉 Your GitReleaseManager bot 📦🚀 |
Description
The initial point here is that we need to refactor the approach of determining the EffectiveConfiguration of a branch. If you ask me it should be dynamic dependent of the VersionStrategy implementation. Thus we need to remove the static logic from the GitVersionContextFactory class and replace it with a really simple logic like GetEffectiveConfiguration in GitVersionContext.cs.
In addition I have changed the following things:
If you have an empty repository you get an Version number 0.0.0.0 instead of an error (which was really bad). This version number functions as a fallback version.(not part of this PR)Reuse or maybe activate a lost feature with the usage of the property TrackMergeTarget. In my opinion the behavior should be always false for the gitflow workflow. The consequence is that in fact the class MergeMessageVersionStrategy.cs is not used for this workflow. Maybe it is good for other scenarios!? (see discussion in [Bug](not part of this PR).track-merge-changes
produces unexpected result when combininghotfix
andsupport
branches #3052 please). Anyway you can set the TrackMergeTarget to true if you want a different behavior.Sometimes I see that after a merge to master or to develop the fourth part of the version number (CommitsSinceVersionSource or I call it revision number) is not calculated correct. For instance if you have three changes in a release lets say 1.0.0 and merge it to master (tag with 1.0.0) an merge back to develop and make one change in develop why would you expect the number 1.1.0+5 (3 from release one from develop and one from merge)? I would say in the next release you have just two commits which differs from the previous release. This behavior is also related to TrackMergeTarget=false which can be configured very quickly.(not part of this PR)Last but not least when a version has been tagged and you rerun it why would you expect that the CommitsSinceVersionSource number is zero? The fourth part of the version number (not the fourth number at semantic version it is always zero) but the CommitsSinceVersionSource (revision) should be like the name says containing the number of commits within this release. There are absolutely no arguments why the BaseVersionCalculator cannot be executed in that case to determine e.g. the BaseVersion.BaseVersionSource of an previous release.(not part of this PR)Resolved Issues
[Bug] Version not generated correct when creating a feature branch from a release branch ( Resolves #3101 )
[Bug] SemVer of a feature branch started from a release branch gets decremented ( Resolves #3151 )
[Bug] Closing pull request from hotfix to support failed to inherit Increment branch configuration ( Resolves #3020 )
[Bug] Wrong semver calculation when making a PR from a hotfix branch to main branch ( Resolves #3187 )
[Bug] Version of commit in develop merged to master changes if master is tagged ( Resolves #3105 )
[Bug] Closing pull request from hotfix to support failed to inherit Increment branch configuration ( Resolves #3020 )
[Bug] Merging develop to release branch makes alpha version jump back ( Resolves #3154 )
Related Issues
[Bug] track-merge-changes produces unexpected result when combining hotfix and support branches #3052(not part of this PR)[Issue] GitVersion produces different BuildMetaData once commit is tagged #1397(not part of this PR)[Issue] track-merge-target in branch config not working #1789(not part of this PR)[Q&A] Prevent decrementation of versions on the develop branch #3177
[Q&A] Increment a feature from the release #3145
Motivation and Context
Here is my view on it and an example how it might be better. All unit tests are adapted right now. The tests I have touched are looking good... That means some unit tests were false positive (or I have a fundamental different view on generating semantic versions). Hope this finds a way to a productive version of GitVersion because I put a lot of effort to this and I want to give something back to this project. GitVersion is great and it should be refactored more in direction of clean code. Thank you very much for given this a chance.
How Has This Been Tested?
I put a lot of time to understand the logic of GitVersion and how it is implemented. For this I have created some additional tests.
Screenshots (if appropriate):
Checklist: