is it possible to set a value on a parameter or to define the default value with the valiable.
e.g.
parameters:
- name: paraA
type: boolean
default: true
value: $(variableA)
#variableA is set in a yaml build in azure devops and for some build it should false and not true
parameters:
- name: paraA
type: boolean
default: ${{ if eq(variable.variableA, false) }}
As I know it's not supported scenario. Variables like variableA are expanded at runtime while parameters like paraA are expanded at template parsing time.
When processing one pipeline, it first expands templates and evaluate template expressions before expanding the runtime variables. The document has stated this:
Related
I set up a variable group called secret-variables and gave it access to my pipeline.
In my pipeline I use a variable template and inside that variable template I define the variable group. I pass the variables from the variable template to pipeline templates using template expression syntax.
azure-pipelines.yml:
trigger:
- master
pool:
vmImage: windows-latest
variables:
- template: pipeline-variables.yml
stages:
- template: templates/myPipelineTemplate.yml
parameters:
mySecretVariable: ${{ variables.mySecretVariable }}
pipeline-variables.yml:
variables:
# secret-variables contain mySecretVariable
- group: secret-variables
- name: foo
value: bar
Yet the value of mySecretVariable in myPipelineTemplate.yml is empty. What have I missed?
It seems that variable groups do not support template expression syntax. Macro syntax needs to be used in stead, change the code in the stage to:
stages:
- template: templates/myPipelineTemplate.yml
parameters:
mySecretVariable: $(mySecretVariable)
This works because macro syntax is evaluated at runtime and template expression is evaluated at compile time.
I have an issue with a variable evaluating to Null on a Condition.
This is the pipeline:
I have a variable template that is pulled in by the main yml file:
variables:
- ${{ if startsWith(variables['Build.SourceBranch'], 'refs/heads/feature/') }}:
- name: is_sandbox
value: true
- ${{ if eq(variables['system.pullRequest.targetBranch'], 'refs/heads/master') }}:
- name: is_sandbox
value: true
- name: bob
value: a
Note that is_sandbox is not set anywhere else.
I then have a condition on job:
condition: or (eq(variables.is_sandbox, true), eq(variables.bob, 'a'))
But this fails to evaluate. In the log is see:
system.pullRequest.targetBranch : refs/heads/master
and:
Expanded: or(eq(Null, True), eq(Null, 'a'))
Result: False
So it appears that the variables template has not set correctly. Why would that be?
Stage variables will only be available to activities within the stage. This is beneficial when reusing variables with different values across different stages. Think potentially stage is tied to an environment and the environment values are different so thus can pass in different variables at the stage level.
I believe you are looking to define these at the root level so variable values will be available to anything in the pipelines unless it is overwritten by a lower level scope.
How can I pass an additional object type variable?
When I try to do this in the yaml file a get an error:
Invalid type found: one of string , number , boolean were expected but an array was found
on: pull_request_review
name: Label approved pull requests
jobs:
labelWhenApproved:
name: Label when approved
runs-on: ubuntu-latest
steps:
- name: Label when approved
uses: ***
env:
APPROVALS:
- value: "1"
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ADD_LABEL: "approved"
REMOVE_LABEL: "awaiting%20review"
The env: section allows you to pass Environment Variables to the actions. The environment variables are key - value. You cannot pass objects.
From GitHub docs:
A map of environment variables
In some cases you can "stringify" a whole object and pass it as an environment variable using toJSON(), but the action itself should "know" how to handle it (e.g to parse the object from the string)
Example how to pass all secrets to an actions:
env:
SECRETS: '${{ toJSON(secrets) }}'
Note: There can be env in different levels in the workflows - you can have them on "global", on a job, or on step (in your case it is a step)
This is a bit of an old question and you've probably found some sort of workaround, but here is an option for you. This is what we do when we need to pass an object into a string input:
env:
APPROVALS: |
- value: "1"
The | converts the next block into a multi-line string. Everything until the next outdentation is a string.
What this means is that your action *** must then use a yaml parser to convert from the string to an object.
I would like to use a common pipeline definition for our solutions. Using variables, I would like to specify solution specific settings. This works, except for a variable group.
I would like to use the pipeline definition in my variable group definition.
For example:
group: $(Build.DefinitionName).Dev
But that does not work. Another option would be to use a pipeline variable, but neither does work:
group: $(buildDefinitonName).Dev
group: {{ variables.buildDefinitonName }}.Dev
What does work is a parameter, but I do not want to specify it for each run.
group: ${{ parameters.buildDefinition }}.Dev
One option is to use your deployment in a template and scope the variable group to a job in that template. The parameter passed into the template would be the environment.
Here is how the template could look:
jobs:
- deployment: Deploy_JobName
variables:
- group: 'ProjectName${{ parameters.stage}}'
The parameter in the template would look like:
parameters:
- name: stage
type: string
This template would be called from a joblike:
jobs:
- template: template.yml
parameters:
stage: ${{ parameters.stage }}
Thanks for your response. Found out that
group: ${{ variables['Build.Definition'] }}.Dev
also works. So you can use predefined variables, but not pipeline variables this way.
I'm attempting to create multiple pipelines in Azure DevOps but I would like to reuse the same pipeline YAML file with the differences per environment being loaded from a separate template variables file.
For that purpose I've created two variable files, which are located in the same folder as the pipeline definition:
# vars.dev.yml
variables:
- name: EnvironmentName
value: Development
# vars.prd.yml
variables:
- name: EnvironmentName
value: Production
And the definition of the pipeline is the following:
trigger: none
pr: none
variables:
- name: EnvironmentCode
value: dev
- name: EnvironmentFileName
value: vars.$('EnvironmentCode').yml
stages:
- stage: LoadVariablesPerEnvironment
displayName: Load Variables Per Environment
variables:
- template: $(EnvironmentFileName)
jobs:
- job: ShowcaseLoadedVariables
steps:
- pwsh: Write-Host "Variables have been loaded for the '$ENV:ENVIRONMENTNAME' environment"
displayName: Output Environment Variables
After importing the pipelines using the Azure DevOps UI, I can go to settings of each and set the Environment Code variable to whatever desired environment code:
However I'm always getting the same error when I try to run the pipeline, regardless of the code I fill in the variable value:
So the question here is: Is this kind of variable expansion not supported or is there a different way that I should use to accomplish this?
Thanks!
EDIT
I was able to expand the variables using another method. The new version of the pipeline is as such:
variables:
- name: EnvironmentCode
value: dev
- name: EnvironmentFileName
value: vars.${{ variables.EnvironmentCode }}.yml
stages:
- stage: LoadVariablesPerEnvironment
displayName: Load Variables Per Environment
variables:
- template: ${{ variables.EnvironmentFileName }}
jobs:
- job: ShowcaseLoadedVariables
steps:
- pwsh: Write-Host "Variables have been loaded for the '$ENV:ENVIRONMENTNAME' environment"
displayName: Output Environment Variables
However there is yet the issue of loading different files. I made different attempts and verified the following:
If you give a different environment code using the UI, when running
the pipeline, the value it assumes is still the one that's on the
pipeline definition;
If you remove from the pipeline definition the
default value or the variable entirely the expression
${{variables.EnvironmentCode}} will return an empty string
assuming the filename to be vars..yml which doesn't exist.
Is this kind of variable expansion not supported or is there a
different way that I should use to accomplish this?
If I am not misunderstand, at first, you want to use $() to get the variable you defined using the UI but failed. But later, ${{ }} can give you the value of the variable EnvironmentCode.
In fact, while you change to use ${{ }}, it just accessing the variable you predefined in the YAML files instead of the one you defined with UI. Just see this doc: Variable templates.
For the variable you defined with UI, it can be get and used with the format $()(Note: ${{ }} is the format of get the variables which defined in YAML file). But also, there some things you need to pay attention is for the variables you defined in UI, it can only be get/accessed after the build begin to run, because the variable which defined with UI exists in environment only after the build compiled begin. In one word, they are the agent-scope variable. That's why the value it used is still the one that's on the pipeline definition instead of on the UI.
If you remove from the pipeline definition the default value or the
variable entirely the expression ${{variables.EnvironmentCode}} will
return an empty string assuming the filename to be vars..yml which
doesn't exist.
As the document defined and I mentioned before, ${{}} is format which used to get the value of variable which defined in YAML files rather than the one which defined using UI.
In the steps of job, the variable that defined in the UI or defined in the YAML file can all be get/accessed with the format $(). Still, for the variable which defined in the YAML file can also get with ${{variables.xxxx}}. But at this time, if the variable name which defined in YAML file is same with the one defined with UI, the server can only get the one defined in YAML file.