Versioning Nuget Package with GitVersion.yml in Azure Devops - azure

I'm stucking with this for a whole week and I didn't reach where i wanted.
I'm thinking about having two branches:
-master
-release(we are calling it vNext - the whole company knows it by this name)
Master branch will generate the packages without prerelease tag.
Release will generate the pre release version like:
=>master is on 1.0.0
=>Create a vNext(release) branch like: vNext/1.1.0
=> Code things needed here and commit;
=> Automatically my pipeline is triggered, because I've set the trigger to branch master, vNext or vNext/*
=> I want this to create a package like (1.1.0-beta1)
=>Create a pullRequest to master
=> Automatically my pipeline is triggered,
=> I want this to create a package like (1.1.0)
This is my gitVersion.yml
next-version: 1.0
mode: Mainline
legacy-semver-padding: 0
build-metadata-padding: 0
commits-since-version-source-padding: 0
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatchTag
assembly-informational-format: '{LegacySemVer}'
branches:
master:
regex: master
increment: Patch
prevent-increment-of-merged-branch-version: true
tag: ''
track-merge-target: false
tracks-release-branches: false
is-release-branch: false
release:
regex: vNext?[/-]
source-branches: ['master']
increment: Patch
prevent-increment-of-merged-branch-version: true
tag: beta
track-merge-target: false
tracks-release-branches: false
is-release-branch: true
I can't get this working fine. To reach where I'm now, I've already googled a lot even here in stackoverflow, but couldn't found a solution that fits in the scenario I need.
Also https://drive.google.com/open?id=1Cy-K3P4ajyUUvvtdt0oa5_NTp1FZ-UIF
This are the logs from builds

As my test, I change your yml as below.
next-version: 1.0
mode: Mainline
legacy-semver-padding: 0
build-metadata-padding: 0
commits-since-version-source-padding: 0
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatchTag
assembly-informational-format: '{LegacySemVer}'
branches:
master:
regex: master
increment: Patch
prevent-increment-of-merged-branch-version: true
tag: ''
track-merge-target: false
tracks-release-branches: false
is-release-branch: false
release:
regex: vNext
source-branches: ['master']
increment: Patch
prevent-increment-of-merged-branch-version: true
tag: beta
track-merge-target: false
tracks-release-branches: false
is-release-branch: true
Then I get the result as this.
Hope this will help.

Related

Getting Schema validation: Incompatible types in detekt.yml in Android Studio

Any way I can fix the schema warning in detekt.yml I am attaching the screenshot and open to add more details
Minimum reproducible detekt.yml below
build:
maxIssues: 0
excludeCorrectable: false
weights:
complexity: 2
LongParameterList: 1
style: 1
comments: 1
config:
validation: true
warningsAsErrors: true
# when writing own rules with new properties, exclude the property path e.g.: 'my_rule_set,.*>.*>[my_property]'
excludes: ''
processors:
active: true
exclude:
- 'DetektProgressListener'
# - 'KtFileCountProcessor'
# - 'PackageCountProcessor'
# - 'ClassCountProcessor'
# - 'FunctionCountProcessor'
# - 'PropertyCountProcessor'
# - 'ProjectComplexityProcessor'
# - 'ProjectCognitiveComplexityProcessor'
# - 'ProjectLLOCProcessor'
# - 'ProjectCLOCProcessor'
# - 'ProjectLOCProcessor'
# - 'ProjectSLOCProcessor'
# - 'LicenseHeaderLoaderExtension'
style:
active: true
ReturnCount:
active: true
max: 2
excludedFunctions: 'equals'
excludeLabeled: false
excludeReturnFromLambda: true
excludeGuardClauses: true
Android version: Android Studio Dolphin | 2021.3.1 Patch 1
Build #AI-213.7172.25.2113.9123335, built on September 30, 2022
Runtime version: 11.0.13+0-b1751.21-8125866 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Okay after some exploration I found out, in the detekt release v1.21.0 they changed all their configuration from comma-separated string to array of string in detekt.yml.
So initially it used to be excludedFunctions: 'equals, hashCode' now they have become excludedFunctions: ['equals', 'hashCode']
After detekt release v1.22.0, they started throwing error while building the project.

GitVersion: always Patch incrementing, Minor is not getting incremented

I have a requirement for Automatic versioning based on branches.
I have set a tag on my master branch as 1.0.0
if changes from feature branch get merged to Master then Minor should get incremented as 1.1.0
if changes from release branch get merged to Master then Patch should be incremented as 1.1.1
but everytime when I merge the code from feature or release branch to master, the patch only get incremented, Minor is not getting incremented. Can anyone help with the branch configuration for my requirement
I have the configuration as below in GitVersion.yml file.
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
assembly-informational-format: '{InformationalVersion}'
mode: Mainline
increment: Inherit
continuous-delivery-fallback-tag: ci
tag-prefix: '\[vV\]'
major-version-bump-message: '+semver:\\s?(breaking|major)'
minor-version-bump-message: '+semver:\\s?(feature|minor)'
patch-version-bump-message: '+semver:\\s?(fix|patch)'
no-bump-message: '+semver:\\s?(none|skip)'
legacy-semver-padding: 4
build-metadata-padding: 4
commits-since-version-source-padding: 4
tag-pre-release-weight: 60000
commit-message-incrementing: Enabled
branches:
feature:
regex: ^features?\[/-\]
mode: ContinuousDeployment
tag: useBranchName
increment: Minor
prevent-increment-of-merged-branch-version: false
track-merge-target: false
source-branches: \[\]
tracks-release-branches: true
is-release-branch: false
is-mainline: false
pre-release-weight: 0
release:
regex: ^releases?\[/-\]
mode: ContinuousDeployment
tag: beta
increment: Patch
prevent-increment-of-merged-branch-version: false
track-merge-target: false
source-branches: \[\]
tracks-release-branches: true
is-release-branch: false
is-mainline: false
pre-release-weight: 0
ignore:
sha: \[\]
merge-message-formats: {}
update-build-number: true

GitVersion jumping versions for a single untagged commit

For a single commit after a tagged commit, GitVersion Commandline suggests a version gap of 42 which coincidentally = CommitSinceVersionSource
The un-tagged commit should be 0.1.0-alpha.42 but GitVersion suggest 0.1.0-alpha0083 (i.e. previous version - 41 + CommitsSinceVersionSource - 42 = 83).
GitVersion.CommandLine
{
"Major":0,
"Minor":1,
"Patch":0,
"PreReleaseTag":"alpha.83",
"PreReleaseTagWithDash":"-alpha.83",
"PreReleaseLabel":"alpha",
"PreReleaseNumber":83,
"BuildMetaData":"",
"BuildMetaDataPadded":"",
"FullBuildMetaData":"Branch.develop.Sha.04c3569fa42b55388d8c133dbf0d3365dfda77be",
"MajorMinorPatch":"0.1.0",
"SemVer":"0.1.0-alpha.83",
"LegacySemVer":"0.1.0-alpha83",
"LegacySemVerPadded":"0.1.0-alpha0083",
"AssemblySemVer":"0.1.0.0",
"AssemblySemFileVer":"0.1.0.0",
"FullSemVer":"0.1.0-alpha.83",
"InformationalVersion":"0.1.0-alpha.83+Branch.develop.Sha.04c3569fa42b55388d8c133dbf0d3365dfda77be",
"BranchName":"develop",
"Sha":"04c3569fa42b55388d8c133dbf0d3365dfda77be",
"ShortSha":"04c3569",
"NuGetVersionV2":"0.1.0-alpha0083",
"NuGetVersion":"0.1.0-alpha0083",
"NuGetPreReleaseTagV2":"alpha0083",
"NuGetPreReleaseTag":"alpha0083",
"CommitsSinceVersionSource":42,
"CommitsSinceVersionSourcePadded":"0042",
"CommitDate":"2021-07-05"
}
GitVersion.yaml
assembly-informational-format: '{DefaultInformationalVersion}'
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
branches:
master:
mode: ContinuousDelivery
tag:
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: main
develop:
mode: ContinuousDeployment
tag: alpha
increment: Minor
prevent-increment-of-merged-branch-version: false
track-merge-target: true
regex: dev(elop)?(ment)?$
feature:
mode: ContinuousDeployment
tag: useBranchName
increment: Inherit
prevent-increment-of-merged-branch-version: false
ignore:
sha: []
How to solve this conundrum ? :)

How to trigger one pipeline stage from another pipeline in Azure DevOps?

In azure DevOps YML pipelines, is it possible to trigger a pipeline A stage1 from pipeline B stageY ?
There's a Trigger Build custom task that you can use. It triggers the whole pipeline, but you can use stage conditions to skip stages that should not run.
# in pipeline A
- task: TriggerBuild#3
displayName: 'Trigger a new build pipelineB'
inputs:
buildDefinition: 'pipelineB'
waitForQueuedBuildsToFinish: true
waitForQueuedBuildsToFinishRefreshTime: 10
buildParameters: 'stageY: true, stageX: false, stageZ: false'
authenticationMethod: 'OAuth Token'
password: '$(System.AccessToken)'
# in pipeline B
variables: [] # do not define stageX, stageY, stageZ variables here, or it won't work
stages:
- stage: stageX
condition: ne(variables.stageX, false)
...
- stage: stageY
condition: ne(variables.stageY, false)
...
- stage: stageZ
condition: ne(variables.stageZ, false)
...

What should be assembly-informational-format be set to in GitVersion.yml

My GitVersion.yml looks like below after I picked up the Global configuration from here
But the problem is, this throws the exception when I run gitversion
Unable to format AssemblyInformationalVersion. Check your format string: 'InformationalVersion' is not a member of type 'GitVersion.SemanticVersionFormatValues' (Parameter 'propertyOrFieldName')
I had to remove the 5th line
assembly-informational-format: '{InformationalVersion}'
to make the exception go away.
I tried the following but did not work.
assembly-informational-format: {InformationalVersion} # removed the quotes.
What am I missing.
next-version: 0.1.0
mode: mainline
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatchTag
assembly-informational-format: '{InformationalVersion}'
increment: Inherit
continuous-delivery-fallback-tag: ci
tag-prefix: '[vV]'
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
no-bump-message: '\+semver:\s?(none|skip)'
legacy-semver-padding: 4
build-metadata-padding: 4
commits-since-version-source-padding: 4
commit-message-incrementing: Enabled
commit-date-format: 'yyyy-MM-dd'
branches:
master:
mode: ContinuousDelivery
tag: ''
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: ^master
tracks-release-branches: false
is-release-branch: false
release:
mode: ContinuousDelivery
tag: beta
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: ^releases?[/-]
tracks-release-branches: false
is-release-branch: true
pre-release-weight: 1000
feature:
mode: ContinuousDeployment
tag: useBranchName
increment: Inherit
prevent-increment-of-merged-branch-version: false
track-merge-target: false
regex: ^features?[/-]
tracks-release-branches: false
is-release-branch: false
pull-request:
mode: ContinuousDelivery
tag: PullRequest
increment: Inherit
prevent-increment-of-merged-branch-version: false
tag-number-pattern: '[/-](?<number>\d+)[-/]'
track-merge-target: false
regex: ^(pull|pull\-requests|pr)[/-]
tracks-release-branches: false
is-release-branch: false
hotfix:
mode: ContinuousDelivery
tag: beta
increment: Patch
prevent-increment-of-merged-branch-version: false
track-merge-target: false
regex: ^hotfix(es)?[/-]
tracks-release-branches: false
is-release-branch: false
support:
mode: ContinuousDelivery
tag: ''
increment: Patch
prevent-increment-of-merged-branch-version: true
track-merge-target: false
regex: ^support[/-]
tracks-release-branches: false
is-release-branch: false
develop:
mode: ContinuousDeployment
tag: unstable
increment: Minor
prevent-increment-of-merged-branch-version: false
track-merge-target: true
regex: ^dev(elop)?(ment)?$
tracks-release-branches: true
is-release-branch: false
ignore:
sha: []
merge-message-formats: {}
So, InformationalVersion is set according to the format specified by assembly-informational-format. So that's likely what's causing the error.
For example, what I've done is something like:
assembly-informational-format: '{MajorMinorPatch}{PreReleaseTagWithDash}+{ShortSha}'
Then, when I run GitVersion, I get back:
"InformationalVersion":"2.0.0-convert-to-netcore.9+abc123"
Again, the documentation is not clear on which variables can be used as part of string interpolation, vs. which variables are set by the various format fields.
UPDATE
I noticed my answer seems to contradict the documentation at GitVersion. However, my experience has demonstrated to me that setting assembly-informational-format influences the value of InformationalVersion, even though InformationalVersion is considered a variable and can be used in interpolation. I think this may be a mistake in GitVersion's documentation. Or at best, that InformationalVersion can be used as a variable in other formats, but because assembly-informational-format is what determines the final value of InformationalVersion, this variable cannot be used in the assembly-informational-format configuration value.
Another Update
OK, I realized that, while the documentation could be better, I've been operating under a misconception about what GitVersion is actually doing/providing. It's not magic (well, it kind of is ;) ), it does require work on your part.
GitVersion is merely calculating some version fields for SemVer and outputs these calculations into a JSON object when you run GitVersion.exe (when using the executable). GitVersion also provides some various common "mash-ups" of these fields, e.g. MajorMinor, MajorMinorPatch, etc. It also provides some ways for you to format complete version numbers, e.g. assembly-file-versioning-format and assembly-informational-format. But in the end, the results of all of these are output to a JSON object.
It is your responsibility to pick and choose from this JSON object, how to construct your version number. So, if you want to use the string from InformationalVersion as your NuGet package version (for v3 package feeds) which is based on the format specified in assembly-informational-format, that's your choice.
GitVersion provides instructions on how you can have this JSON object "converted" into either build variables or environment variables that can be accessed from your build process. It's up to you to ensure you configure your build to use these values to achieve your desired versioning scheme. But GitVersion only calculates the major/minor/patch version number and attempts to help you format pre-release and build metadata tags.
This revelation certainly helped me understand better how to configure GitVersion and use it in my build processes.

Resources