In my release pipeline for a dotnet core project, I want to increment the assembly version automatically so I don't need to update it manually each time. This is so my Nuget version is increased every time.
At the moment I'm using the dotnet pack command and adding the build number at the end using the "Automated Package Versioning" set to "Use Environment Variable: Build.BuildNumber". Then I set the "Option > Build Number Format" to "1.0.$(BuildID)". First, I tried setting the attribute of the .csproj file to 1.0.$(BuildID), but the pipeline did not pick that up.
The problem is that I have to edit my build pipeline every time I want to adjust my major or minor semver version. Yet with the teams, we agreed not to put build pipeline config in source control (yaml files). Is there a way we can put a part of the build pipeline in a yaml file so that we can override parts of the configuration?
For example: I could set the "Build Number Format" to "$(Major).$(Minor).$(BuildID)" and then the partial yaml could override the Major and Minor variables.
How to set up automatic nuget version increments
If you want to automatic nuget version increments, you could use the BuildNumber $(Rev:r) instead of $(BuildID):
Run (build) number:
$(Rev:r)
2 (The third run on this day will be 3, and so on.)
Use $(Rev:r) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
If you want to show prefix zeros in the number, you can add additional
'r' characters. For example, specify $(Rev:rr) if you want the Rev
number to begin with 01, 02, and so on.
So, you could set the Build Number Format to $(Major).$(Minor)$(Rev:.r).
Hope this helps.
Related
I need to exclude a job from pipeline in case my project version is pre-release.
How I know it's a pre-release?
I set the following in the version info file, that all project files and tools use:
version = "1.2.3-pre"
From CI script, I parse the file, extract the version value, and know whether it's a pre-release or not, and can set the result in an environment variable.
The only way I know to exclude a job from pipeline is to use rules, while, I know also from gitlab docs that:
rules are evaluated before any jobs run
before_script also is claimed to be called with the script, i.e. after applying the rules.
I can stop the job, only after it starts from the script itself, based on the version value, but what I need is to extract the job from the pipeline in the first place, so it's not displayed in the pipeline history. Any idea?
Thanks
How do you run (start) your pipeline, and is the information whether "it's a pre-release" already known at this point?
If yes, then you could add a flag like IS_PRERELEASE as a variable to the pipeline, and use that in the rules: section of your job. The drawback is that this will not work with automatic pipelines (triggered by a commit or MR); but you can use this approach with manually triggered pipelines (https://docs.gitlab.com/ee/ci/variables/#override-a-variable-when-running-a-pipeline-manually) or via the API (https://docs.gitlab.com/ee/ci/triggers/#pass-cicd-variables-in-the-api-call).
I've created a powershell script that updates a Pipeline Variable during a Release Pipeline. It takes the custom variable and updates it with a new version using semantic versioning with every run.
I've tried to add this custom variable as the Release Pipeline but keeps on giving me an error "Names of releases from this pipeline will not be unique. Use pre-defined variables to generate unique release names."
I've tried setting the variable to "Settable at Release" and putting the scope to "Release"
Does anybody perhaps know if there is a way to let the release pipeline know this is a dynamic variable that changes?
The only other option is to add the revision number to it $(versionnumber)$(rev:.r)
use Custom Pipeline Variable for Release Name
For this issue ,I think it not feasible to achieve it. Release name must be a unique name,
the $(rev:r) token can ensure that every completed build/release has a unique name because it's adding a incremental number for each release. When a build/release is completed, if nothing else in the number has changed, the Rev integer value is incremented by one. So, basically we cannot achieve that without using $(rev:r), unless you can defined a token which has the same function with $(rev:r).
In addition,you can also use $(Build.BuildNumber) or $(Release.ReleaseId) which are also unique.
For the similar issue,please refer to this case .
I want to change release names like V.1.0.00 for manual release in Continuous Delivery of Azure DevOps but i can't able to delete or change the naming without this $(rev:r), how can I use a custom name?
Default Name: Release- $(rev:r)
Required Name: V.1.0.0
In the build Pipeline.
You can customize how your pipeline runs are named/numbered. Ref : https://learn.microsoft.com/en-us/azure/devops/pipelines/process/run-number?view=azure-devops&tabs=yaml
In YAML, this property is called name.
Use variables to set your major version, minor version etc and generate the patch version using counter Ref : https://learn.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops#counter.
for your case you can set
major : V.1
minor : 0
patch : $[counter(format('{0}.{1}', variables['major'], variables['minor']), 1)]
and set the name like
name: $(major_version).$(minor_version).$(patch_version)
Release pipeline
Refer to $(Build.BuildNumber) which will ref to the buildpipeline custom name/number set in the build pipeline. You can change this naming scheme by editing the release name format mask. In the Options tab of a release pipeline, edit the Release name format property in the General page. Ref : https://learn.microsoft.com/en-us/azure/devops/pipelines/release/?view=azure-devops#how-do-i-manage-the-names-for-new-releases.
You can change the naming scheme by editing the release name format mask.
When specifying the format mask, you can use the pre-defined variables mentioned in this official document or custom variable -- the value of a global configuration property defined in the release pipeline.
But for your issue ,as far as I know, no pre-defined variables can be displayed like V1.0.0 as release name.
You can't. release name must be a unique name, therefore Azure DevOps requires you to put $(rev:r) in the name, because it's adding a incremental number for each release.
Another option is to use $(Build.BuildNumber) or $(Release.ReleaseId) that are also unique but is not will solve your issue.
Our Goal is to have Auto versioning for npm and NuGet packages in release definition of Azure Pipelines
As of now we are using the tokenization task based on the rev value we replacing the version numbers in both nuspec and package.json files.
So we getting the version numbers like 1.0.1, 1.0.2….. like this and auto versioning achieved in release definition
But the problem is whenever the release fails we are losing those numbers as our version numbers because rev value is increasing
Example: If my published version of artifacts is 1.0.1..
Next version to be published for me is 1.0.2
But if the 1.0.2 release is failed and if 1.0.3 is succeeded we are getting published number as 1.0.3 here for end user 1.0.2 is missing
Now we need the help to increment my version number based on last successful release or to reset the rev value based on the successful release or to get the published version of artifacts and increase that number
Or any other best practices to accomplish this task will be helpful.
Thank you in advance.
NPM with NuGet package auto versioning
I am afraid there is no such way to accomplish this task directly. Because $(Rev:.r) is the build number on this day. Use $(Rev:.r) to ensure that every completed build has a unique name. When a build is completed, if nothing else in the build number has changed, the Rev integer value is incremented by one. This value stores in database.
As test, I have created a Inline Powershell task to modify the value when build/release task fails.
I use the powershell script Write-Host "##vso[build.updatebuildnumber]$newVersionNumber" to update the build.updatebuildnumber (I use build.updatebuildnumber as nuget package version.) and set the option Run this task as Only when a previous task has failed:
To see which variables you can use for build and release pipelines, check these pages: - Build variables - Release variables.
Following is the powershell scripts to modify the build.updatebuildnumber:
$vstsCurrentVersionNumber = $Env:BUILD_BUILDNUMBER
$currentVersionNumber = $vstsCurrentVersionNumber.Split(".")
$revisionNumber = $currentVersionNumber[3]
$newRevisionNumber = [int]$revisionNumber -1
$newVersionNumber = $currentVersionNumber[0] + "." +
$currentVersionNumber[1] + "." + $currentVersionNumber[2] + "." +
$newRevisionNumber
$env:VersionNumber = $newVersionNumber
Write-Host "Update Build Number To: $newVersionNumber"
Write-Host "##vso[build.updatebuildnumber]$newVersionNumber"
Indeed, if the build/release task failed, the build number will be modified at this building.
However, when we execute the build/release next time, the buildnumber/$(Rev:.r) still increase based on the last failed build result:
As workaround, we could set a value for the nuget package version, like 1.0.0. And add a Inline Powershell task to increase the value of the version by one each time, when we successfully build/release. Do not execute Inline Powershell task when the build/release fails.
Hope this helps.
I am using Install Script in Install Shield 2013 on Windows 7, Lang Used C#.
I have a project and it has some features and sub features added to it. Now I want to build a new release using Automation Interface need to add some selective features/ subfeatures to this release so that the original features remains unaltered.
We can pass the New release name and features required in this release using Command Line.
How can I add selective features supplied as command line arguments to my release. Is there any predefined Object/function/Method for this. Please advise.
Need to achieve this in Install Script only.
We can do so by using IncludeInBuild() property of ISWiFeature. It alters the default IncludeInBuild value of a feature.
To make it temp store the current values of the features to be altered in a list , then build a new release. After making new release, once again assign the value stored in list to the altered features.