Add CustomVersion output variable - #5098
Conversation
|
Nice catch. I haven't found any issues with the implementation. The only point I'd like to raise is that, from a conceptual point of view, I think this property should be configurable on a per-branch basis if we want to properly support e.g. PEP 440. See: |
d07f576 to
13ac2ff
Compare
13ac2ff to
5723c9e
Compare
|
@HHobeck move the property to BranchConfiguration instead, please review |
internal record BranchConfiguration : IBranchConfiguration
{
[JsonPropertyName("custom-version-format")]
[JsonPropertyDescription($"Specifies the format of CustomVersion. Defaults to '{DefaultCustomVersionFormat}'.")]
[JsonPropertyDefault($"'{DefaultCustomVersionFormat}'")]
public string? CustomVersionFormat { get; set; }
...
}I would prefer not to define fallback configuration values in code. We usually rely on predefined workflows to provide default values, which makes those defaults transparent to the end user. Also, I'm not sure a default value of Edit: |
Good catch |
|
I was also thinking about removing DeploymentMode and using the new formatting scheme to generate the different version formats instead. That would require a more generic property name than custom-version-format. The DeploymentMode effects only how the semver will be formatted. What do you think? @asbjornu |
|
Maybe I'm wrong and it is more then just formatting: 
|
|
I will focus only on adding the possibility to specify a custom version format so it can be used to generate custom version and later we can decide on how to extend or make it more generci |
06ee9eb to
51f7a58
Compare
|
|
Queued — the merge queue status continues in this comment ↓. |
Merge Queue Status
This pull request spent 14 seconds in the queue, including 2 seconds running CI. Required conditions to merge
|
|
Thank you @arturcic for your contribution! |
2 participants
Description
Adds a configurable
CustomVersionoutput variable controlled bycustom-version-format. The format supports the existing version-variable and environment-variable formatters and defaults to{SemVer}without changing the semantics of existing outputs.The value is available in JSON output, generated version files, WiX output, and the MSBuild
GetVersiontask. Configuration, CLI override, output approvals, documentation, and generated schemas are updated as well.Related Issue
Closes #1674
Closes #2065
Closes #3340
Closes #4659
Supersedes the implementation attempted in #4659 and follows the design described in discussion #4272.
Motivation and Context
Consumers sometimes need a version format with semantics different from GitVersion's standard outputs. Examples covered by this change include:
0.6.3beta10.0001000.For #1674, separators in a branch-derived label can be removed with the PascalCase formatter:
When the exact replacement must be controlled—for example, preserving
JIRA.123instead of reducingJIRA-123toJira123—replace{PreReleaseLabel:c}with an environment variable containing the desired RPM-safe label:How Has This Been Tested?
dotnet build ./src/GitVersion.slnx --no-restoredotnet test --project ./src/GitVersion.Configuration.Tests/GitVersion.Configuration.Tests.csproj --no-restore— 97 passeddotnet test --project ./src/GitVersion.Output.Tests/GitVersion.Output.Tests.csproj --no-restore— 123 passeddotnet test --project ./src/GitVersion.MsBuild.Tests/GitVersion.MsBuild.Tests.csproj --no-restore— 151 passeddotnet format ./src/GitVersion.slnx --verify-no-changes --no-restoreA broader Core test run reached an unrelated timing-sensitive failure in
PerformanceScenarios.RepositoryWithALotOfTags(3518 ms versus the 2500 ms threshold); all CustomVersion-related tests pass.Checklist