-
Notifications
You must be signed in to change notification settings - Fork 657
Introduce CustomVersion
variable
#4659
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
base: main
Are you sure you want to change the base?
Conversation
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.
Pull Request Overview
This PR introduces a new CustomVersion
output variable and associated custom-version-format
configuration option to provide users with a customizable version string that doesn't affect existing semantics. This addresses compatibility issues with tools like NuGet that don't fully follow semantic versioning rules.
Key changes:
- Added
CustomVersion
property toGitVersionVariables
with configurable formatting - Introduced
custom-version-format
configuration option with default value{SemVer}
- Updated test outputs and documentation to include the new variable
Reviewed Changes
Copilot reviewed 22 out of 22 changed files in this pull request and generated 5 comments.
Show a summary per file
File | Description |
---|---|
src/GitVersion.Core/OutputVariables/GitVersionVariables.cs | Added CustomVersion property to the record and included it in property collections |
src/GitVersion.Core/Configuration/IGitVersionConfiguration.cs | Added CustomVersionFormat property to configuration interface |
src/GitVersion.Configuration/GitVersionConfiguration.cs | Implemented CustomVersionFormat configuration property with JSON serialization attributes |
src/GitVersion.Core/VersionCalculation/VariableProvider.cs | Added logic to format and provide CustomVersion variable |
docs/input/docs/reference/variables.md | Updated documentation to include CustomVersion variable description |
schemas/6.4/GitVersion.configuration.json | Added custom-version-format to configuration schema |
Various test files | Updated approved test outputs to include CustomVersion in generated code |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
@arturcic Why did you revert the doc change on my branch? Also, confused as to why some of the App tests are failing e.g. Is there another mechanism other than |
One other question is whether the changes should be under the 6.4 schema or be bumped to a 6.5 schema? |
The schema is updated as part of the release |
That's not me who updated, but of you want to change the configuration.md you need to update mdsource instead |
ade0456
to
31323e6
Compare
Can we approve this now or is there something else to do? |
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 think this looks good in terms of the code. But the commits are a bit messy. Could you please clean them up a bit? There's also an issue with the coverlet step failing on the windows-2025
runner.
Calculating coverage result...
C:\Users\runneradmin\.nuget\packages\coverlet.msbuild\6.0.4\build\coverlet.msbuild.targets(72,5): error : Unable to read beyond the end of the stream. [D:\a\GitVersion\GitVersion\src\GitVersion.App.Tests\GitVersion.App.Tests.csproj::TargetFramework=net8.0]
C:\Users\runneradmin\.nuget\packages\coverlet.msbuild\6.0.4\build\coverlet.msbuild.targets(72,5): error : at System.IO.BinaryReader.ReadInt32() [D:\a\GitVersion\GitVersion\src\GitVersion.App.Tests\GitVersion.App.Tests.csproj::TargetFramework=net8.0]
C:\Users\runneradmin\.nuget\packages\coverlet.msbuild\6.0.4\build\coverlet.msbuild.targets(72,5): error : at Coverlet.Core.Coverage.CalculateCoverage() in /_/src/coverlet.core/Coverage.cs:line 420 [D:\a\GitVersion\GitVersion\src\GitVersion.App.Tests\GitVersion.App.Tests.csproj::TargetFramework=net8.0]
C:\Users\runneradmin\.nuget\packages\coverlet.msbuild\6.0.4\build\coverlet.msbuild.targets(72,5): error : at Coverlet.Core.Coverage.GetCoverageResult() in /_/src/coverlet.core/Coverage.cs:line 160 [D:\a\GitVersion\GitVersion\src\GitVersion.App.Tests\GitVersion.App.Tests.csproj::TargetFramework=net8.0]
C:\Users\runneradmin\.nuget\packages\coverlet.msbuild\6.0.4\build\coverlet.msbuild.targets(72,5): error : at Coverlet.MSbuild.Tasks.CoverageResultTask.Execute() in /_/src/coverlet.msbuild.tasks/CoverageResultTask.cs:line 87 [D:\a\GitVersion\GitVersion\src\GitVersion.App.Tests\GitVersion.App.Tests.csproj::TargetFramework=net8.0]
Ideas @arturcic?
using var _ = this.fileSystem.SetupConfigFile(path: this.repoPath, text: text); | ||
var configuration = this.configurationProvider.ProvideForDirectory(this.repoPath); | ||
|
||
configuration.CustomVersionFormat.ShouldBe("custom-version-format-from-yml"); |
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.
Should we have tests for non-constant strings as well?
Can I just do a squash commit/rebase to tidy the commits up - surely you do a squash on merge anyway? |
No, we don't do squash merge commits. We like to keep the commit history and merge commits, but in this case it's a bit messy. If you want to rebase and squash everything into one commit, that's fine by me. 👍🏼 |
Also, not sure how to address the flaky windows/qodana builds |
No, it seems unrelated to this PR. I'm hoping @arturcic has an idea. |
I noticed that as well, not much we can do at this point. We can re-run the failed jobs for the windows and that will succeed the second time, qodana usually fails whenever the global.json sdk is updated, it takes time for their action to update for the latest sdk |
390eb01
to
49ff7a3
Compare
|
@asbjornu I've squashed the commits, is there anything else I need to do? |
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.
Just one last question, otherwise this looks good to me!
Following options are supported: | ||
1. `assembly-file-versioning-format` |
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.
Why is assembly-file-versioning-format
removed?
Bad merge - I’ll add it backSent from my iPhoneOn 21 Sep 2025, at 16:41, Asbjørn Ulsberg ***@***.***> wrote:
@asbjornu approved this pull request.
Just one last question, otherwise this looks good to me!
In docs/input/docs/usage/cli/arguments.md:
@@ -113,13 +113,13 @@ Double quote character inside of the double quoted `value` has to be be escaped
Following options are supported:
…-1. `assembly-file-versioning-format`
Why is assembly-file-versioning-format removed?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Introduces a new output variable
CustomVersion
and an associated formatting variablecustom-version-format
Description
Intent is to allow the user to define an output variable without changing the semantics of existing ones. This can then be used to resolve issues such as providing an appropriate version to tools such as NuGet which do not fully followed semantic versioning rules.
Related Issue
Motivation and Context
See above
How Has This Been Tested?
Additional tests in
ConfigurationProviderTest
for custom-version-format and updated test outputs elsewhere to alignChecklist: