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 .
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 need to take down Azure VMs in a controlled way, first stopping them and then removing them. The "stop" part needs to be executed only if the VM is existing, otherwise the task creates one in a stopped state, and then removes it. I tried variations on when: state == "present" but without success. Where can I find an example or documentation about how I can use that? Or maybe the solution to have a previous task retrieving the VM info, and act on that?
TIA!
If you haven't tried already, give it a try by having the first task using the module "azure_rm_virtualmachine_info" and make sure you save the result to a variable using "register" command. Then have the second task using "when" command to check if the value is "present" or not for the state object of the variable thats saved in the earlier task.
I have certain expressions used by multiple steps in Azure Data Factory.
For instance, I get the start time of a pipeline often:
#formatDateTime(pipeline().TriggerTime, 'yyyy-MM-dd HH:mm:ss.fff')
If I need to change it for some reason, I'd need to update it everywhere.
I know about global parameters; however, is there a way to create global expressions?
Based on my knowledge, currently there is no way to have a global expression similar to Global parameters.
For you have to have a common source of truth or 1 common expression, I would suggest you to create a common pipeline in the ADF and call that pipeline via execute pipeline activity to avoid re writing the same code every where.
You could add a variable to the pipeline and set it to the appropriate value at the start of your pipeline run: https://learn.microsoft.com/en-us/azure/data-factory/control-flow-set-variable-activity
You can then refer to this variable as you do with parameters or change its value on the go.
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.
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