How to set a release name based on build run name / variable when releasing from an Azure DevOps YAML pipeline?

Question

We are trying to migrate our deployment from Classic to YAML based pipelines.

It seems to work fine so far, but I cannot figure out how to set the release name (the one listed in the "Status" column in "Environments") such that it is or contains the build pipeline run name or a variable defined in it?

How do I set the release name showing up in "Environments" to something determined in a build pipeline defined as resources / trigger?

For context:

We determine the version number we show to end user in the build pipeline. It mainly depends on the branch name, the commit date and some kind of commit counter within that date.

We are naming our build pipeline runs and releases with this end user name.

What I found out so far:

• Using the powershell command Write-Host "##vso[build.updatebuildnumber]$triggerBuildNumber", I can set the name displayed in "Pipelines", but it it does not change the release name.
• Using the powershell command Write-Host "##vso[release.updatereleasename]$triggerBuildNumber" fails with the error message release commands are not supported for Build flow.
  • I also noticed that System.HostType is set to build. From the documentation, I would have expected deployment in a deployment job.
• Using the name: field on the pipeline's root level sets both the pipeline run and the release name, but it seems I cant't access build pipeline parameters from there

Example pipeline code:

trigger:
  - none

resources:
  pipelines:
    - pipeline: build_pipeline
      source: Tool_build
      trigger:
        branches:
          - main
          - project_split

variables:
  - name: pipelineNumber
    value: $(resources.pipeline.build_pipeline.runName)

# This actually sets the release name, but the pipelineNumberVariable is not evaluated
name: Tool Deployment $(Date:yyyyMMdd)$(Rev:rr)-$(pipelineNumber)

stages:
  - stage: DeployAndChangePipelineName
    dependsOn:
    jobs:
      - deployment: DeployJob
        environment: 'Beta'
        strategy:
          runOnce:
            deploy:
              steps:
                - powershell: |
                    $buildNumber = "$(resources.pipeline.build_pipeline.runName)" 
                    # Next line renames pipeline, but not release.
                    Write-Host "##vso[build.updatebuildnumber]$buildNumber"

  - stage: DeployAndChangeReleaseName
    dependsOn:
    jobs:
      - deployment: DeployJob
        environment: 'Production'
        strategy:
          runOnce:
            deploy:
              steps:
                - powershell: |
                    $hostType = "$(System.HostType)"
                    # Next line shows "build" when I would expect "deployment".
                    Write-Host "Host Type: $hostType"
                    
                    $buildNumber = "$(resources.pipeline.build_pipeline.runName)" 
                    # Next line fails, probably because Azure DevOps because hostType behaves like a build job.
                    Write-Host "##vso[release.updatereleasename]$buildNumber"

Answer 1

Regarding the two issues discussed in this post:

1. Variable Expansion in Pipeline Run Names: The pipeline resource variable $(resources.pipeline.build_pipeline.runName) does not expand in the run/build name of the downstream pipeline, which includes a deployment job referencing a pipeline environment. This has resulted in an unexpected deployment display name within this environment.

2. Updating Deployment Display Names: Although the run/build name of your pipeline for can be changed by the logging command ##vso[build.updatebuildnumber], the deployment display name in the referenced environment remains unchanged.

While I can't agree more that this behavior is unexpected, I am afraid it is currently a limitation of the pipeline environments, which display the run/build name as it was assigned at the time of build creation. To address this, I recommend submitting a feature request via the Visual Studio Developer Community. This will allow you to directly interact with the Product Group and facilitate the collection and categorization of your suggestions. The Product Group will review the priority of this use case and consider it for future updates if it meets their criteria.