Branch's increment not used when merging feature branch in main #4430
Comments
|
This is only possible with TrunkBased workflow. Please see the following integrations tests: [Test]
public void __Just_A_Test_1__()
{
using var fixture = new EmptyRepositoryFixture("main");
var configurationBuilder = GitFlowConfigurationBuilder.New
.WithBranch("main", builder => builder
.WithIncrement(IncrementStrategy.Minor)
.WithDeploymentMode(DeploymentMode.ContinuousDelivery)
.WithPreventIncrementOfMergedBranch(true)
).WithBranch("hotfix", builder => builder.WithIncrement(IncrementStrategy.Patch));
fixture.MakeATaggedCommit("1.0.0");
fixture.BranchTo("hotfix/foo");
fixture.MakeACommit();
fixture.MergeTo("main");
fixture.AssertFullSemver("1.1.0-2", configurationBuilder.Build());
}
[Test]
public void __Just_A_Test_2__()
{
using var fixture = new EmptyRepositoryFixture("main");
var configurationBuilder = TrunkBasedConfigurationBuilder.New
.WithBranch("main", builder => builder
.WithIncrement(IncrementStrategy.Minor)
.WithDeploymentMode(DeploymentMode.ContinuousDelivery)
.WithPreventIncrementOfMergedBranch(true)
).WithBranch("hotfix", builder => builder.WithIncrement(IncrementStrategy.Patch));
fixture.MakeATaggedCommit("1.0.0");
fixture.BranchTo("hotfix/foo");
fixture.MakeACommit();
fixture.MergeTo("main");
// ✅ succeeds as expected
fixture.AssertFullSemver("1.0.1-2", configurationBuilder.Build());
}This feature was introduced in the mainline version strategy and needs to be implemented in MergeMessageVersionStrategy. |
|
Hi @HHobeck, Thank you very much for your response, I highly appreciate it! I must confess that I am a bit confused though. I removed all regex from the I did not find the tests you posted in the repo's tests. I read through a lot of them, especially in the FeatureBranchScenarios and could not find a scenario that a feature branch is merged and then main gets a minor version bump. I tried to use again the GitHubFlow example and the TrunkBasedFlow example configurations but I get the same results. You said that "it" needs to be implemented in MergeMessageVersionStrategy. What do you mean by "it"? I had configured it (at various points in my tests) like so: In any case, I would like to use a "mix" of GitHubFlow and TrunkBasedFlow.
The configuration below is the final configuration that I would like to have, which I think is correct for what I want. Would you be so kind as to explain what combination or single setting is wrong or missing or redundant, that is responsible for my troubles? OR if I have not understood your point(s) and I am misusing some configuration(s), can you let me know what do I need to do to achieve my goals above? Thank you so much again for helping out!!! 😊🥰 |
I have just posted the tests to illustrate the different between the two workflows. They are not in the repository present.
You can find your scenario in the following integration test:
Okay then you need to maybe go some steps back and start from the beginning by using just the
Actually this behavior we are talking about is something which was implemented in Mainline mode (OLD, in version 5.x) and migrated to the new Mainline version strategy (NEW, in version 6.x). Yes, it's a feature which is worth to implement in MergeMessage version strategy. I have created a new feature ticket for this:
I'm sorry if I can't fulfill your expectation. Please understand that I cannot provide advice/consultancy on individual workflows. However, you are free to engage me or other experts to help you. Thank you very much for your understanding. |
|
Hi @HHobeck, Thanks for getting back to me so soon! I got that you posted example tests and they were not copied from the repository itself. What I meant is I could not find them or their counterparts, in the repository while reading all related tests to what I am trying to accomplish. I did not come across At first your comment and example test threw me off, since you said that what I wanted should work on TrunkBased workflow and the example test was mentioning a hotfix branch with specific naming rule, and the assertion in the test was for a I will try again and use the My excuses again if I asked too much in the end of my previous comment. It just felt easier to ask the question "what is wrong with this then??" than a gazillion of others. If you had pinpointed the problem, then I would try and figure out myself what went wrong in my previous attempts. So, all in all, I will give it another try and if in need bother you some more 😬 |
|
Hi @HHobeck, I spend some time trying out using the I then tried again to create a simple configuration from scratch and this time I left the Since the I tried to understand how it works It seems that for this strategy to be even used:
Then and only then the It seems to me that the Thus it seems that what I am aiming for, cannot be done using I can perhaps describe it with a test [Test]
public void MergingFeatureBranchInMainUsesBranchIncrement()
{
using var fixture = new EmptyRepositoryFixture("main");
// No specific Flow builder, but an empty/custom flow
var configurationBuilder = EmptyConfigurationBuilder.New
.WithBranch("main", builder => builder
.WithIncrement(IncrementStrategy.Patch)
.WithDeploymentMode(DeploymentMode.ContinuousDelivery)
.WithPreventIncrementOfMergedBranch(true) // ignore the Patch when a feature branch is merged in main
.WithPreventIncrementWhenBranchMerged(false)
.WithIsMainBranch(true)
).WithBranch("feature", builder => builder
.WithIncrement(IncrementStrategy.Minor)
.WithRegularExpression("(?<BranchName>.+)")
.WithDeploymentMode(DeploymentMode.ManualDeployment)
.WithPreventIncrementOfMergedBranch(true)
.WithPreventIncrementWhenBranchMerged(false) // don''t ignore Minor when merging this branch to main
.WithIsReleaseBranch(false)
);
fixture.MakeATaggedCommit("1.0.0");
fixture.BranchTo("feature-foo");
fixture.MakeACommit();
fixture.MergeTo("main");
fixture.AssertFullSemver("1.1.0-2", configurationBuilder.Build());
}So could it be that the issue #4433 you created can be generalized for other custom flows and not only be about the GitHubFlow? |
prantzos
changed the title
Like I mentioned in the ticket:
Of course this behavior will be applying to all workflows (including custom workflows) which are using the |
|
Hi @HHobeck, When I say "other custom flows", I am not referring to I was referring to workflows that do not follow a predefined/approved template, by setting the workflow as empty as described in the documentation. 
If as you say the behavior will apply to all workflows, including custom ones, then my question above regarding how the code of MergeMessageVersionStrategy works still stands. My apologies if my example does not make sense to you. I tried to explain what I am trying to accomplish with snippets from GitVersion.yml, with a fake test method and with explaining the behavior in bullet points, but it seems I failed to convey my point. If you see something missing, like a required configuration property, as you mentioned above, please indicate which one(s) you believe is missing that is required and I have missed to configure properly. I am posting here the full GitVersion.yml that I am currently working with, with all branch configurations and strategies for your reference.
## You can configure branching strategy in GitVersion.yml. See: https://gitversion.net/docs/reference/configuration
## Bump the next version explicitly. Use for bumping the major version increment.
#next-version: 4.0
workflow: ''
tag-prefix: ''
tag-pre-release-weight: 90000
assembly-informational-format: '{SemVer}.{ShortSha}'
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatchTag
commit-date-format: yyyy-MM-dd
update-build-number: true
commit-message-incrementing: Enabled
merge-message-formats:
git: "^Merge branch '.*'"
strategies:
- Fallback
- ConfiguredNextVersion
- MergeMessage
- TaggedCommit
branches:
main:
regex: ^master$|^main$
mode: ContinuousDelivery
label: ''
increment: Patch
prevent-increment:
of-merged-branch: true
when-branch-merged: false
when-current-commit-tagged: true
track-merge-target: false
track-merge-message: false
source-branches: [ ]
is-source-branch-for: [ ]
is-release-branch: false
is-main-branch: true
feature:
regex: ^(WT-.*)
mode: ManualDeployment
label: 'rc'
increment: Minor
prevent-increment:
of-merged-branch: true
when-branch-merged: false
when-current-commit-tagged: false
track-merge-target: false
track-merge-message: false
source-branches:
- main
- feature
is-source-branch-for: [ ]
is-release-branch: false
is-main-branch: false
hotfix:
regex: ^hotfix[/-](?<BranchName>.+)
mode: ContinuousDelivery
label: 'patch'
increment: Patch
prevent-increment:
of-merged-branch: true
when-branch-merged: true
when-current-commit-tagged: false
track-merge-target: false
track-merge-message: false
source-branches:
- main
is-source-branch-for: [ ]
is-release-branch: false
is-main-branch: false
unknown:
regex: (?<BranchName>.+)
mode: ManualDeployment
label: ''
increment: Patch
prevent-increment:
of-merged-branch: true
when-branch-merged: true
when-current-commit-tagged: false
track-merge-target: false
track-merge-message: false
source-branches:
- main
- feature
- unknown
is-source-branch-for: [ ]
is-release-branch: false
is-main-branch: falseI would appreciate it if you could indicate which required properties are not set, or have a wrong value. And again, many thanks for helping out! 🙏 |
|
Yes no problem I can help you out with your custom workflow. But therefor you need to engage me. Please contact me per email to agree on the conditions. |
|
Oh yes okay sure, I can contact you via email 👍 |
Hi,
I would like your help with a configuration that even though simple, I could not get it to work and I believe there is a bug here.
I have attempted many many different variations and I cannot compose a GitVersion.yml that does the following:
I removed any other configurations for hotfix and other non-default properties and regular expressions to keep it simple, but still the strategy followed is the increment value of the main branch which is "Patch" instead of the "Minor" which is of the merged branch
This is my GitVersion.yml
dotnet-gitversion output on the main branch before merging the
test-branch%dotnet-version
dotnet-gitversion of the feature branch
Merging a branch
% git merge test-branch
...
dotnet-gitversion with diagnostic output on the main branch after merging the
test-branchAnd the commits from the git log are the following:
% git log --merges --oneline
Maybe a combination of the
prevent-incrementand theincrementmakes it so that the merging strategy does not work as expected.I would appreciate any response, help, feedback and potentially a bug fix if that indeed is the case.
Originally posted by @prantzos in #4425
The text was updated successfully, but these errors were encountered: