-
|
My first experiment had gone well. I had simulated a release cycle and got a 1.1.0 release, and then the develop branch started reporting 1.2.0 based version numbers, which was good. I then started simulating a second release cycle, and that's where things have gone awry. The git status is as follows:
The tags have been added by the CI/CD process based on what gitversion reports. The master, develop and release/* branches get tagged. The latest build of the "release/1.2" branch however is now reporting a version of 1.2.0-alpha.2. This is presumably because this is an explicit tag on this commit, despite that tag being added "to the develop branch" (added as a tag from a build of that branch). My GitVersion.yaml file is empty, so config is standard. The output from gitversion is: This seems to suggest that at least automatically applying tags to the "develop" build is a bad idea, or at least does an unexpected thing. Any suggestions on how I modify my usage, configuration, or CI/CD workflow to produce a more expected output? Thanks |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 21 replies
-
|
What would you consider "a more expected output" in the given scenario? |
Beta Was this translation helpful? Give feedback.
-
|
Naively, I've built code from the "release/1.2" branch. The gitversion configuration for that branch is that there should be a pre-release tag of "beta" on the version numbers. Instead, I've got an "-alpha" pre-release tag. I'm just trying to understand how gitversion works and trying to construct some kind of human workflow and CI/CD pipeline for some kind of release process. Gitversion seems to be set up by default for "git flow" so I was trying to simulate that. At the moment it seems that I either need to stop automatically tagging builds on the develop branch or I need to add an artficial empty commit having created a release branch, otherwise builds from the release branch don't always get the right version number. |
Beta Was this translation helpful? Give feedback.
-
|
Automatically tagging non-stable releases seems superfluous, yes. You should preferably only need to tag stable releases. |
Beta Was this translation helpful? Give feedback.
-
|
It takes notice of the "prerelease label" in the branch configuration in other circumstances:
So here, although the commit has a tag on it, the semver it's calculated has inherited the pre-release label from the branch config. This is different to what happened on my release branch. Just for clarity. I created the feature branch feature/feature3, and the semver was taken from the build of that branch. Note that here also, the "1.2" version confused me. Previously the develop branch automatically bumped to 1.2 when I had released 1.1. Here that doesn't seem to have happened. |
Beta Was this translation helpful? Give feedback.
-
|
In terms of tagging builds on develop, the motivation was just to produce a "snapshot" or "nightly" build that can be downloaded and used by developers. This isn't uncommon. The natural way to do that is to create a tag, but I suppose it doesn't have to be a tag that is of the form "v1.2.3". |
Beta Was this translation helpful? Give feedback.
-
|
Actually I notice that I got the same |
Beta Was this translation helpful? Give feedback.
-
|
Correct. When several branches point to the same commit, it's ambiguous to GitVersion which branch it should consider for version calculation. |
Beta Was this translation helpful? Give feedback.
-
|
But git knows that the "current" branch is just one of those doesn't it? I think that's probably the bit that's confusing to me here. It appears to be ignoring the fact that the current branch is the "release/1.3" branch and so not applying the gitversion branch configuration pre-release tag. |
Beta Was this translation helpful? Give feedback.
-
|
The feature branch in the gitflow workflow has a increment strategy set to inherit. Thus in your scenario it inherits from develop and release branch. I would recommend you to use the beta release: https://github.com/GitTools/GitVersion/releases/tag/6.0.0-beta.2 |
Beta Was this translation helpful? Give feedback.
-
|
#2340 appears to describe the situation I'm seeing, where a tag exists that doesn't match the configuration of the current branch. |
Beta Was this translation helpful? Give feedback.
-
|
It's a general problem. From the repository point of view the state is the same until you are creating an additional commit on develop or release branch: [TestCase("develop")]
[TestCase("release/1.1.0")]
public void __Just_A_Test__(string branch)
{
var configuration = GitFlowConfigurationBuilder.New.Build();
using var fixture = new EmptyRepositoryFixture("main");
fixture.MakeATaggedCommit("1.0.0");
fixture.BranchTo("develop");
fixture.MakeACommit("1");
fixture.BranchTo("release/1.1.0");
// ✅ succeeds as expected
fixture.AssertFullSemver("1.1.0-beta.1+0", configuration);
fixture.Checkout("develop");
// ✅ succeeds as expected
fixture.AssertFullSemver("1.2.0-alpha.0", configuration);
fixture.Checkout(branch);
fixture.BranchTo("feature/foo");
fixture.MakeACommit("2");
// ✅ succeeds as expected
fixture.AssertFullSemver("1.2.0-foo.1+1", configuration);
}The scenario says if you create a feature branch from a develop or a release branch it makes no different when the release and the develop branch points to the same commit. It yields to the highest version which might be not expected. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not really sure I understand that test case. The only tag involved there is the initial 1.0.0 tag. So the versions it comes up with seem reasonable, but not obviously the scenario I'm thinking of.
|
Beta Was this translation helpful? Give feedback.
-
|
There are breaking changes in yaml configuration? |
Beta Was this translation helpful? Give feedback.
-
|
The title of this discussion is: Could you please focus on this question and mark it as answered if it has been answered. |
Beta Was this translation helpful? Give feedback.
-
|
But all of this is to do with that. Fundamentally it is solved by that 2340 fix |
Beta Was this translation helpful? Give feedback.
-
May I ask you: Why do you expect the semantic version of a tag to be ignored just because the pre-release label is different on the branch? See [Bug] Consider pre-release tags only when they matching with the label name on branch #3438. [Test]
public void Just_A_Test()
{
var configuration = GitFlowConfigurationBuilder.New.Build();
using var fixture = new EmptyRepositoryFixture("main");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver($"0.0.1-1", configuration);
fixture.BranchTo("develop");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver($"0.1.0-alpha.2", configuration);
fixture.ApplyTag($"1.0.0-alpha.2");
// ✅ succeeds as expected
fixture.AssertFullSemver($"1.0.0-alpha.2", configuration);
fixture.BranchTo("release/next");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver($"1.0.0-beta.1+3", configuration);
} |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Isn't that what that change implements though? It appears to at least. Indeed the test I wrote shows that behaviour, assuming I've written my test correctly: If you weren't using gitversion you might implement this part of the logic in your Jenkinsfile for example. You might write logic in your Jenkinsfile like I appreciate that it is possible to check out a tag and build the code from that, and it's then potentially ambiguous what the branch is, and so potentially make reproducing a build from the same commit ambiguous. I don't think I've ever rebuilt from a tag ever. The 99.9999% case is always "build the tip of branch xyz", and then tag that afterwards as "I built this and it generated a build with version blah". |
Beta Was this translation helpful? Give feedback.
-
|
Actually I'm not sure if I can follow your thoughts. Of course you can specify the pre-release label per branch. And of course the pre-release label of an tag will be ignored (and the pre-release number will be not reset) if the label on the branch differs. But the pre-released version number (which comes from a semantic version from a tag with a foreign pre-relesae label) will be cosidered. Are you agree? That means the expectation that the tag will be completely ignored is not correct. Expected: [Test]
public void Just_A_Test()
{
var configuration = GitFlowConfigurationBuilder.New.Build();
using var fixture = new EmptyRepositoryFixture("main");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver($"0.0.1-1", configuration);
fixture.BranchTo("develop");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver($"0.1.0-alpha.2", configuration);
fixture.ApplyTag($"1.0.0-alpha.2");
// ✅ succeeds as expected
fixture.AssertFullSemver($"1.0.0-alpha.2", configuration);
fixture.BranchTo("release/next");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver($"1.0.0-beta.1+3", configuration);
}Not Expected: [Test]
public void Just_A_Test()
{
var configuration = GitFlowConfigurationBuilder.New.Build();
using var fixture = new EmptyRepositoryFixture("main");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver($"0.0.1-1", configuration);
fixture.BranchTo("develop");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver($"0.1.0-alpha.2", configuration);
fixture.ApplyTag($"1.0.0-alpha.2");
// ✅ succeeds as expected
fixture.AssertFullSemver($"1.0.0-alpha.2", configuration);
fixture.BranchTo("release/next");
fixture.MakeACommit();
/// ❌ expected: 1.0.0-beta.1+3
fixture.AssertFullSemver($"0.1.0-beta.1+3", configuration); // <<--- the tag 1.0.0-alpha.2 should be considered but not the label name
} |
Beta Was this translation helpful? Give feedback.
-
|
I'm confused where this thread has gone. What am I missing? |
Beta Was this translation helpful? Give feedback.
-
|
Okay no problem. Just want to ensure that we are on the same page and the behavior in 6.0.0 is like you expecting it. |
Beta Was this translation helpful? Give feedback.
The feature branch in the gitflow workflow has a increment strategy set to inherit. Thus in your scenario it inherits from develop and release branch. I would recommend you to use the beta release: https://github.com/GitTools/GitVersion/releases/tag/6.0.0-beta.2