0

We are implementing a naming convention for our release pipelines. It follows this format:

Priority.Team.Product

Some of our release pipelines are already in the format Priority.Team.Product and no changes are necessary. Others are named Team.Product and I need to add the Priority. prefix to make the names compliant.

To do this, I created a new task group variable "Priority.ReleaseDefinitionName". Its default value is $(Release.DefinitionName).

In a PowerShell script task with an inline script, I check to see if the Priority. is present or missing and change the name accordingly in a local variable called $name.

At the end of the script, I try to set Priority.ReleaseDefinitionName to the value of $name this way:

Write-Host "##vso[task.setvariable variable=Priority.ReleaseDefinitionName;]$name"

Unfortunately, this is not working. The variable name remains unchanged in the subsequent tasks. The value of $name is correct but the value of $(P1.ReleaseDefinitionName) is not.

What am I missing?


I tried using the following code to set the variable name:

Write-Host "##vso[task.setvariable variable=Priority.ReleaseDefinitionName;]$name"

Expected result is the value of $(Priority.ReleaseDefinitionName) has been changed to the value of $name in subsequent tasks.

Acutal result is the value of $(Priority.ReleaseDefinitionName) remains unchanged.

  • Hi, how is your pipeline built? Do you have multiple stages? If so, do you set the `Priority.ReleaseDefinitionName` in one stage and then are you trying to access that variable in the next stage? Providing more code from your pipeline will help people paint a better picture of what you are trying to accomplish and eliminate assumptions :). – Robert Jun 14 '23 at 09:23
  • Task group has `$(Priority.ReleaseDefinitionName)` as a parameter. The parameter has a default value of `$(Release.DefinitionName)`. First task is a PowerShell script that reads from that variable and sets it at the end. The subsequent tasks in the task group read the original default value as if the variable has not been changed. Workaround I discovered was to have no default value. It almost appears as if the parameter is treated as a constant rather than a varaible. – Cliff Schomburg Jun 15 '23 at 17:03

2 Answers2

0

Short answer:

It appears Azure DevOps Server treats the parameter as a constant rather than a variable.


Detailed answer:

I noticed that I was unable to set the value if there was a default value already set. It appears the parameter is treated as a constant rather than a variable.

Because the variable was required, I had to export the task group to a JSON object and change the variable to optional. I imported the JSON object as a new task group.

When there was no default value, it allowed me to set the variable's value in the first task in the task group and read the new value in subsequent tasks in the task group.

Ultimately, I ended up deleting the parameter all together from the JSON and importing the JSON without it. It now acts as a variable but does not show as a parameter which prevents users from actually setting the default value.

-1

It should work. yaml example:

- powershell: |
   $var1 = "var value 1"
   $var2 = "var value 2"
   $var3 = "var value 3"
   $var4 = "var value 4"
   $name = "New Release Def Name"
   
   Write-Host "##vso[task.setvariable variable=my.var1]$var1"
   Write-Host "##vso[task.setvariable variable=my.var2]$var2"
   Write-Host "##vso[task.setvariable variable=my.var3]$var3"
   Write-Host "##vso[task.setvariable variable=my.var4]$var4"
   Write-Host "##vso[task.setvariable variable=Priority.ReleaseDefinitionName]$name"
   
  displayName: 'Set vars'
  condition: and(succeeded(), in('2', '2','3'))

- powershell: |
   Write-Host "Var1:" $Env:MY_VAR1 "Var1:" $(my.var1)
   Write-Host "Var2:" $Env:MY_VAR2 "Var2:" $(my.var2)
   Write-Host "Var3:" $Env:MY_VAR3 "Var3:" $(my.var3)
   Write-Host "Var4:" $Env:MY_VAR4 "Var4:" $(my.var4)
   Write-Host "ReleaseDefinitionName:" $Env:PRIORITY_RELEASEDEFINITIONNAME "ReleaseDefinitionName:" $(Priority.ReleaseDefinitionName)
   
   
  displayName: 'Read vars'

Result:

enter image description here

Shamrai Aleksander
  • 13,096
  • 3
  • 24
  • 31
  • Exactly - it *should* work. I was wondering if the "." in the name was a problem but your example rules that idea out. Maybe the variable name is too long? – Cliff Schomburg Jun 14 '23 at 15:28
  • @CliffSchomburg I use the same name in my example `Priority.ReleaseDefinitionName` – Shamrai Aleksander Jun 14 '23 at 15:55
  • I may have discovered the issue. It appears if the variable is already set with a default value, I cannot set it again later in the pipeline. It appears to behave as a constant rather than a variable. Is that the case for you as well? – Cliff Schomburg Jun 15 '23 at 16:56