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.
Related
i am currently facing an issue using Gitlab-ci. i am using gitlab 13.12 community edition.
I want to be able to override the value of a CICD variable from within a gitlab-ci.yml job.
you might say that i could just pass out the value from one job to another but the goal is to change that value so that , on the next pipeline , all my jobs will use the updated one.
To be precise , i want to be able to change MY_CICD_VARIABLE_TO_CHANGE that i've defined in project > cicd > variables. and update this value from a gitlab-ci job
something like this but not only change it for the current pipeline but update it :
change_variable_value:
stage: "change_variable"
image: myimage
script:
- $MY_CICD_VARIABLE_TO_CHANGE="value_changed"
, i tried to do every single solutions specify here :
https://docs.gitlab.com/13.12/ee/ci/variables/index.html#override-a-defined-cicd-variable
nothing seems to work.
I also tried to use artefact but it seems that i am not able to pass artefact between 2 distinct pipelines, they have to be part of the same pipeline , even by curling the api (at least in the community edition)
Any idea is more than welcome :)
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.
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 can get to the artifact location by hard coding it:
$(System.DefaultWorkingDirectory)\_Testing-CI\test\
But can I somehow get the source alias and artifact name from some variables in the release?
It looks like it is now possible to use $(Release.PrimaryArtifactSourceAlias). This would mean your artifact drop is at: $(System.DefaultWorkingDirectory)/$(Release.PrimaryArtifactSourceAlias)/drop
It is currently not possible to get the source alias name/Artifact name from the environment variable.
As of now, you need to specify the Artifact alias name in order to access the artifact related information.
E.g, Release.Artifacts.{alias}.DefinitionName
General Artifact variables
Primary Artifact Variables
As per here
You can use the default variables in two ways - as parameters to tasks
in a release pipeline or in your scripts.
You can directly use a default variable as an input to a task. For
example, to pass Release.Artifacts.{Artifact alias}.DefinitionName for
the artifact source whose alias is ASPNET4.CI to a task, you would use
$(Release.Artifacts.ASPNET4.CI.DefinitionName).
To use a default variable in your script, you must first replace the .
in the default variable names with _. For example, to print the value
of artifact variable Release.Artifacts.{Artifact
alias}.DefinitionName for the artifact source whose alias is
ASPNET4.CI in a Powershell script, you would use
$env:RELEASE_ARTIFACTS_ASPNET4_CI_DEFINITIONNAME
Note that the original name of the artifact source alias,
ASPNET4.CI, is replaced by ASPNET4_CI
You can upvote this feedback in order to achieve your request
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.