I have a release pipeline with a variable, but there doesn't seem to be any way to set the value of that variable to something that's evaluated at release time. For example, another variable.
Here's a real example:
All I want to do is set the value of MyExpressionBasedVariable to the value of MyOtherVariable.
All the docs and examples online seem to suggest it's possible, but I can't get it to work. I always end up with the literal string rather than the evaluated value.
I've tried using these different syntaxes:
$(MyOtherVariable)
$[variables['MyOtherVariable']]
${{variables['MyOtherVariable']}}
I've seen that you can define custom tasks to set variable names as part of the pipeline but this seems massively overkill.
Essentially all I want to do is rename a key vault secret to a different variable name for convention-based XML variable replacement in config files.
E.g. I have a secret called this-is-a-secret-name-which-is-a-different-naming-convention-to-my-connectionstrings but I need it in a variable called MySecret-ConnectionString.
How do I use the value of another variable in a release pipeline variable?
How do I use the value of another variable in a release pipeline variable?
As I test, what you set should be work. You can try to follow below steps to check if you still have this issue:
Create a new release pipeline without link any variable group.
Set the Variable like following:
Add a Run Inline Powershell task to output the value of the Variable:
Write-Output 'The value of MyExpressionBasedVariable is $(MyExpressionBasedVariable)'
Write-Output 'The value of $(MyOtherVariable) is $(MyOtherVariable)'
Then we could get the log:
So, what you set should be work, if this still does not work for you, then you need to make sure that the variable you describe in the question is the variable your actual test.
Besides, at this moment, the value of nested variables (like $(TestVar_$(Release.Reason))) are not yet supported in the build/release pipelines, check this thread for some details, so make sure there are no such nested variables in your project.
Hope this helps.
Related
I am trying to look for a solution where our developers want to deploy a different version of their build. My train of thought was to add an env variable to our cicd configs, and then in our cd playbook evaluate if that var is None, and if so override the version we normally get from the package or pom file.
This is turn will grab that XXX version from our helm and docker container registry allowing them to roll back without or redeploy an older version quickly and efficiently.
I see that Azdo provides environment variables, but I wanted something that would only set or store the env variable for the run from the pipelines and would not be persistant.
You can configure so-called queue time variables. The idea is that you set a default value, like latest, and check the for to change the value at queue time:
If a variable appears in the variables block of a YAML file, its value is fixed and can't be overridden at queue time. Best practice is to define your variables in a YAML file but there are times when this doesn't make sense. For example, you may want to define a secret variable and not have the variable exposed in your YAML. Or, you may need to manually set a variable value during the pipeline run.
You have two options for defining queue-time values. You can define a variable in the UI and select the option to Let users override this value when running this pipeline or you can use runtime parameters instead. If your variable is not a secret, the best practice is to use runtime parameters.
To set a variable at queue time, add a new variable within your pipeline and select the override option.
Set a variable at queue time.
To allow a variable to be set at queue time, make sure the variable doesn't also appear in the variables block of a pipeline or job. If you define a variable in both the variables block of a YAML and in the UI, the value in the YAML will have priority.
See:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?WT.mc_id=DOP-MVP-5001511&view=azure-devops&tabs=yaml%2cbatch#allow-at-queue-time
I am trying to create a simple Runtime Variable in my Release Pipeline that carries the BuildNumber of the Triggering Artifact.
I tried adding a variable called alias and in the value column I wrote $(Release.TriggeringArtifact.Alias) And I set the Settable at Release Time to true.
Then I added another variable called BuildNumber and I wrote this in the value column: $(Release.Artifacts{alias}.BuildNumber} and set the Settable at Release Time to true.
I have a powershell task that Echoes the value of my variable BuildNumber. I was expecting the build number that was assigned to my artifact, but what I see is the git repository's name instead.
How can I have release time variables with pre-defined variables substituted in them?
What you are trying to do is to use nested variable which is not supported:
Thanks for your patience on this. I checked with the product team and there are places where variables will expand when nested, and the behavior will be slightly different if you specify variables with macro syntax (example: $(var)). However, this is not an officially supported feature and their recommendation is to not document macro variables as expanding recursively.
If you would like to reach out the product team directly, please post in the Azure DevOps Developer Community. The product team actively monitors that space.
You can also vote on this on developer community
I am creating a build pipeline (YAML) with some "Powershell" task in it in which all are not inline scripts. I need to have a PSCustomObject that can be passed as a global variable (this param should be accessible across the pipeline). For example, it needs to be used like this. $myPSObject.value1 in first task, $myPSObject.value2 in second task etc. Is it possible?
Any leads would be much appreciated.
No, this is definitely not possible, what you can do, however, is cast it to json (compressed would, probably, make more sense) and then in your steps read it and cast it back to an object and work with it like you normally would. You'd need to use azure devops build variable for that, not powershell variable
I have a web application that I build and release using TFS. The release definition contains a task group with all the necesarry steps for the deployment of the web application.
What I want to do is to determine a certain value and store it in a variable to use later on in the release proccess in the other release tasks.
At this moment, the first step in de task group is a Powershell task that determines the necessary value and stores it in an environment variable using:
Write-Output ("##vso[task.setvariable variable=MyVar;]$var")
When I use this environment variable in the next Task (Again, a PowerShell task), it runs perfectly as expected using:
Write-Host "Doing stuf for: $env:MyVar"
It's when I want to use the variable as a parameter for (multiple) different task(s) when it gets weird. When the environment variable has no default value, the calculated value from the first PowerShell task is used and all is well. But TFS doesn't like it when environment variables have no default value and forces to provide one before being able to save the release definition again. When I provide a default value, the task that uses the variable as Task parameter uses the default value, instead of the calculated value. I would expect that the calculated value should be used, as the second PowerShell task ensures that the calculated value is properly stored.
So, the symptoms I see:
When not providing a default value, the code in scripts as wel as the task parameters use the calculated value
When providing a default value, the code in scripts use the calculated value and the task parameters use the default value
Is there something I do wrong, or am I using environment variables wrong and should I use a different method?
As I understand it, you want to define your variable in a powershell-task within the task group, but you are also being forced to provide a value in the environment variable, causing the variable sometimes to have the value set in the powershell, sometimes to have the value defined in the environment variable.
The solution is to just provide the name of the environment variable itself, so it always gets overwritten by the value you set in the powershell task.
Source: https://blogs.msdn.microsoft.com/harshillodhi/2016/11/29/vststfs-understanding-task-groups-and-its-various-use-cases-with-setvariable-logging-command/
Under the header "What is a setvariable logging command and how to use it with Task Groups?", three scenario's are referenced. It sounds like the second scenario may fit your needs.
I'm moving my configuration from using web.config transforms to being based on VSTS variables. I get process variables, you define a variable, pick an environment, and you're good to go. I also see "Variable Groups", these seem great, have KeyVault integration, and overall seem like a much better option.
But...I don't see a way to bind a Variable Group to a specific environment in my VSTS release process. I can't honestly see how these would be any use to me without this feature.
I've experimented with one workaround, but it didn't work. I tried:
Naming my variable group & variables with an environment prefix e.g.
Variable Group Name="Production ConnectionStrings"
Variable name="Production_LoggingConnectionString"
I thought once I linked the "Production_ConnectionStrings" variable, I could reference $(Production_LoggingConnectionString) from within a standard Process variable, but this didn't work.
I think I could come up with some powershell that would do something like the above and set variables, but this seems a bit too custom for me.
Does anyone else have an idea that I can use variable groups per environment, easily, without waiting around for VSTS to build this feature (if ever). Btw, if you want this feature, there is a suggestion here you can upvote: Make it possible to link a variable group to a specific environment in a release definition
This has now been implemented in VSTS variable groups as scopes. Go to your release definition -> Variables -> Variable Groups -> Link variable group, and you get the link window as below, where you can choose the scope to be either release or one or more of your environments!
I did not manage to find any release information on this feature, I just stumbled upon it as I was tweaking my releases.
I ended up using a powershell script to define my process variable based on the variable groups, it works great.
Let's say I want a variable named "LoggingConnectionString" and this has different values per environment
Steps:
Define a Variable group, e.g. "SharedLoggingVariables"
Inside this Variable group, define a variable/value for each environment, e.g. "LoggingConnectionStringDev", "LoggingConnectionStringProduction"
Back in your Process Variables for the Build/Release, make SURE you don't have a variable named "LoggingConnectionString", otherwise this will overwrite the value coming from the variable group
In your Release process, create a Powershell inline script at the beginning of the Agent with the following code
Param(
[string]$LoggingConnectionString
)
Write-Host "##vso[task.setvariable variable=LoggingConnectionString]$LoggingConnectionString"
Pass your variable group as an argument to this inline powershell, e.g.
-LoggingConnectionString "$(LoggingConnectionStringDev)"
The final powershell step should look something like this:
During release, the powershell will set your process variable from the variable groups. If powershell isn't an option for you, there are other options
No, there is no way to use variable Groups per environment.
As the user voice you linked, you can vote and follow up for the suggested feature.
The work around for now is using environment variables to overwrite the variables in variable Group.
Assume the variable LoggingConnectionString with the value Server=myDB in variable group need to be used both for Dev environment and staging environment. But for staging environment, it needs to use another value (such as Server=stageDB) from the variable LoggingConnectionString. So you can add the an environment variable LoggingConnectionString with the value Server=stageDB for staging environment.
When the variable $(LoggingConnectionString) is used in Dev environment, it will use the value (Server=myDB) defined in variable group.
When the variable $(LoggingConnectionString) is used in staging environment, since the variables both defined in environment variable and variable group, it will use the value (Server=stageDB) defined in environment variable.