[Bug] Closing pull request from hotfix to support failed to inherit Increment branch configuration #3020
Comments
asbjornu
changed the title
|
With GitVersion 5.10.3, this is the output I get: {
"Major": 1,
"Minor": 0,
"Patch": 2,
"PreReleaseTag": "PullRequest0002.2",
"PreReleaseTagWithDash": "-PullRequest0002.2",
"PreReleaseLabel": "PullRequest0002",
"PreReleaseLabelWithDash": "-PullRequest0002",
"PreReleaseNumber": 2,
"WeightedPreReleaseNumber": 30002,
"BuildMetaData": null,
"BuildMetaDataPadded": "",
"FullBuildMetaData": "Branch.pull-2-merge.Sha.cde794da99c75e1997ad38167e0fec05fabfb1e7",
"MajorMinorPatch": "1.0.2",
"SemVer": "1.0.2-PullRequest0002.2",
"LegacySemVer": "1.0.2-PullRequest0002-2",
"LegacySemVerPadded": "1.0.2-PullRequest0002-0002",
"AssemblySemVer": "1.0.2.0",
"AssemblySemFileVer": "1.0.2.0",
"FullSemVer": "1.0.2-PullRequest0002.2",
"InformationalVersion": "1.0.2-PullRequest0002.2+Branch.pull-2-merge.Sha.cde794da99c75e1997ad38167e0fec05fabfb1e7",
"BranchName": "pull/2/merge",
"EscapedBranchName": "pull-2-merge",
"Sha": "cde794da99c75e1997ad38167e0fec05fabfb1e7",
"ShortSha": "cde794d",
"NuGetVersionV2": "1.0.2-pullrequest0002-0002",
"NuGetVersion": "1.0.2-pullrequest0002-0002",
"NuGetPreReleaseTagV2": "pullrequest0002-0002",
"NuGetPreReleaseTag": "pullrequest0002-0002",
"VersionSourceSha": "919c847f718e25c6669717146e11a0542fdc709f",
"CommitsSinceVersionSource": 2,
"CommitsSinceVersionSourcePadded": "0002",
"UncommittedChanges": 0,
"CommitDate": "2022-09-03"
}Perhaps you can write up your test case and expected version assertions as a |
|
I think I am facing the same issue here when I create a PR from a hotfix branch int master. I am not a C# developer but here's how I imagine the test would be. [Test]
public void CalculatesCorrectVersionAfterHotfixBranchMergedToMain()
{
using var fixture = new EmptyRepositoryFixture();
fixture.Repository.MakeATaggedCommit("1.0.0");
fixture.Repository.MakeACommit();
Commands.Checkout(fixture.Repository, fixture.Repository.CreateBranch("hotfix/1.0.1"));
fixture.Repository.MakeACommit();
fixture.Repository.MakeACommit();
fixture.Repository.CreatePullRequestRef("hotfix/1.0.1", MainBranch, normalise: true);
fixture.AssertFullSemver("1.0.1-PullRequest2.2");
}Hope this help. Please keep us posted for any workaround. |
|
I managed to execute the test above. I actually get the required result that is 1.0.1-PullRequest. Unfortunately, this is not the case when the PR is created by AzureDevops. Maybe the test fixture does not match what is actually done by Azure Devops. I am available if you need any further information. |
|
@NightFox7, I suppose you will have to create a remote repository and then clone that to a local one to reproduce AzDO's behavior. You can see an example of how that's done in the following test: |
|
I will try to re-run the issue with newer version, I didn't clone a repo from azdo, the test case I've submitted it's a vanilla git repository created exactly with the repro steps I've attached. If @asbjornu results is |
|
I've re-run it the exact same repro steps with version
with the same warning:
remember to add the mode: ContinuousDeployment
branches:
master:
tag: beta
increment: Minor
pull-request:
tag: alpha-pr
support:
tag: beta
ignore:
sha: []
merge-message-formats: {} |
|
@asbjornu I manage to create a repro as fixture here: |
|
I have taken a look to the following test: [Test]
public void WithRemote()
{
var fixture = PrepareLocalRepo();
var local = fixture.CloneRepository();
local.Checkout("origin/hotfix/v1.0.2");
local.BranchTo("hotfix/v1.0.2");
local.Checkout("origin/support/v1.0.x");
local.BranchTo("support/v1.0.x");
local.Checkout("origin/main");
local.BranchTo("main", "main");
local.AssertFullSemver("1.1.0-beta.1", config);
local.Checkout("pull/2/merge");
local.AssertFullSemver("1.0.2-alpha-pr0002.2", config);
local.Repository.DumpGraph();
}
|
|
Even because if you check the OnlyLocal test it is just working fine, the remote version instead doesn't work, so there's should be a subtle bug somewhere |
|
@micdenny, If I change the { "pull-request", new BranchConfig { Tag = "alpha-pr", Increment = IncrementStrategy.Patch} }, |
Sorry @asbjornu, I don't get how this can help me, pull-request has to follow the targeting branch versioning style, in fact in the local version simply works, I don't understand why it doesn't work when there is also one remote in the same repo. In other words, when I open a PR against master, I want to increase the minor part so basically the Increment strategy of pull-request should be inherit, as it is by default:
|
|
Okay, so setting I'm not sure why |
yes, but then if we add a test closing the PR against
I can give it a try |
|
I figure out where the problem is, but not why:
in somehow the remote is messing up probably with the
will continue investigate later |
|
Nice find, @micdenny. Thanks for digging into this! |
|
It is not
I would not change this behavior, probably you want to know that I think I'll go with a sanitation of the Hold on ⏳ |
Nope the problem it's not directly related to
If we exclude remotes then the name comparer used in So basically I'm in a clamp, one of the two flow has to be changed.
|
|
🎉 This issue has been resolved in version 6.0.0 🎉 Your GitReleaseManager bot 📦🚀 |
|
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. |
|
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. |
The version chosen when closing a pull request from hotfix branch to support branch is wrong because gitversion doesn't choose the right parent branch.
GitVersion.yml
I have a couple of case that you can look at it.
case 1 remote + local branches
case 2 remote/local only
The
pull/x/mergeis the branch that is automatically created from azure devops pull request, and the build pipeline use that branch to build from, and I would like to have a proper version even in that case to generate a very early pre-release version.Expected Behavior
case 1 remote + local branches
case 2 remote/local only
Actual Behavior
case 1 remote + local branches
case 2 remote/local only
Steps to Reproduce
case 1 remote + local branches
case 2 remote/local only
Your Environment
The text was updated successfully, but these errors were encountered: