-
|
Hi All, I'm having a bit of trouble trying to achieve something and I'm wondering if anyone has any pointers on what to try. Background: I am using a GitHub style flow, and would like to be able to have specific version bumps without any code changing. Example: I have my main branch: This is what my config looks like: mode: Mainline
legacy-semver-padding: 1
build-metadata-padding: 1
commits-since-version-source-padding: 1
commit-message-incrementing: Disabled
tag-prefix: ''
increment: Patch
branches:
main:
tag: alphaWhen GitVersion computes the version rather than incrementing to |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 6 replies
-
|
A slightly less edge case example of bumping without changes. Is bumping from patch to new minor: mode: Mainline
legacy-semver-padding: 1
build-metadata-padding: 1
commits-since-version-source-padding: 1
commit-message-incrementing: Disabled
tag-prefix: ''
increment: Minor
branches:
main:
tag: '' |
Beta Was this translation helpful? Give feedback.
-
|
Please see the following discussion: and feature: Same version computed on different branches #3453 I'm not sure how it fits to the version mode mainline because in manline alias trunk based workflow you are normally not using tags. BTW you should switch to the preview version of git version if you want to have the discussion to be at the latest stage. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @HHobeck for the information. Regarding the discussion and feature, I don't think they're 100% related to what I'm looking to achieve.
Thanks you were correct, after a bit more research I believe I want
I've upgraded to 6.0.0-beta.2. My new config looks like: However, I still don't seem to be able to achieve what I'm looking for (interestingly, I now get an error entirely, rather than it just keeping the old version). Example; I have 2.0.0-alpha.1 release cut from This is what I see when running GitVersion trying to do this: |
Beta Was this translation helpful? Give feedback.
-
|
Actually I cannot follow your thoughts. Could you please create a integartion test for your scenario? [Test]
public void Just_A_Test()
{
var configuration = GitFlowConfigurationBuilder.New
.WithVersioningMode(VersioningMode.ContinuousDeployment)
.WithBranch("main", builder => builder
.WithLabel("ci")
.WithVersioningMode(VersioningMode.ContinuousDeployment)
)
.Build();
using var fixture = new EmptyRepositoryFixture("main");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver("0.0.1-ci.1", configuration);
// or
// ❌ expected: 0.0.1-ci.5
fixture.AssertFullSemver("0.0.1-ci.1", configuration);
} |
Beta Was this translation helpful? Give feedback.
-
Why would you set the increment property to inherit on the main branch? |
Beta Was this translation helpful? Give feedback.
-
Ah, this was something left over from testing, it worked on 5.x so I guess something changed on 6.x, switching to
Let me look into this a bit more and see if I can come up with something for this. |
Beta Was this translation helpful? Give feedback.
-
|
I think this test is what I want to do, but looking at the test, I don't think it is possible. (Copied from this test) [Test]
public void NextVersionShouldBeIncrementedIfNoCommitToBranch()
{
var configuration = GitHubFlowConfigurationBuilder.New
.WithLabel(null)
.WithBranch("main", branchBuilder => branchBuilder
.WithVersioningMode(VersioningMode.ContinuousDelivery)
.WithLabel(null).WithIncrement(IncrementStrategy.Patch)
).Build();
using var fixture = new EmptyRepositoryFixture("main");
fixture.MakeATaggedCommit("1.0.0");
fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver("1.0.1-1+1", configuration);
fixture.ApplyTag("1.0.1-alpha.1");
// ✅ succeeds as expected
fixture.AssertFullSemver("1.0.1-alpha.1", configuration);
// Do not do fixture.MakeACommit();
// ✅ succeeds as expected
fixture.AssertFullSemver("1.0.1-alpha.2", configuration);
}A bit of background about the use case here, as it is somewhat weird. We have our application, but then we also have separately managed variables/secrets. These variables/secrets are versioned as well (and leverage the same versioning as the application that uses them). The issue that can occasionally happen is that we need to update the variables/secrets, so we need to increment their version. In keeping things in sync, we also want to increment our application version to the same version as our variables/secrets. However, in some cases, there haven't been any commits to the application since the last release, so we run into an issue where GitVersion doesn't increment. I know there is a relatively simple workaround of just committing some change to the application, but this adds a bit more overhead, that I would like to avoid if possible. Note, this isn't really a significant amount of overhead, so if this is something that GitVersion doesn't/can't easily support, creating a "empty" commit is still a viable option. |
Beta Was this translation helpful? Give feedback.
-
|
Okay thank you for outlining it. It gives me a better understanding for what you want. :)
GitVersion is a tool to determine the semantic version based on the current state of the repository. If you have no changes in the repository then the same configuration yields to the same result (deterministic). The pre-release number reflects the number of commits which have been made from the base version of the previous release. Without additional commits the pre-release number will be remain the same even if you change the next-version number. The only way I can think of is:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks, for the information and help! |
Beta Was this translation helpful? Give feedback.
Okay thank you for outlining it. It gives me a better understanding for what you want. :)
GitVersion is a tool to determine the semantic version based on the current state of the repository. If you have no changes in the repository then the same configuration yields to the same result (deterministic). The pre-release number reflects the number of commits which have been made from the base version of the previous release. Without additional commits the pre-release number will be remain the same even if you change the next-version number. The only way I can think of is: