DRAG DROP
-
You have an Azure Pipeline.
You need to store configuration values as variables.
At which four scopes can the variables be defined, and what is the precedence of the variables from the highest precedence to lowest precedence? To answer, move the appropriate scope from the list of scopes to the answer area and arrange them in the correct order.
Eliminate task and the answer is from the least letters to most letters, to memorize better
Great way to memorize it, gotta love it!
This is how I learned at school, now I don't remember anything. Start studying by understanding not memorizing!
I agree, but I don't think tests like this help that haha.
I agree, but I don't think tests like this help that haha.
1. job 2. stage 3. pipeline root 4. pipeline settings UI https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#variable-scopes In the YAML file, you can set a variable at various scopes: - At the root level, to make it available to all jobs in the pipeline. - At the stage level, to make it available only to a specific stage. - At the job level, to make it available only to a specific job. When you define a variable at the top of a YAML, the variable is available to all jobs and stages in the pipeline and is a global variable. Global variables defined in a YAML aren't visible in the pipeline settings UI. Variables at the job level override variables at the root and stage level. Variables at the stage level override variables at the root level.
What about tasks ? The task can have and env (environment) section that maps from other values. Can those variables instead of mapping have direct assignment ? That would mean that a task can have its own variables too.
Seems correct. When you set a variable with the same name in multiple scopes, the following precedence applies (highest precedence first). Job level variable set in the YAML file Stage level variable set in the YAML file Pipeline level variable set in the YAML file Variable set at queue time Pipeline variable set in Pipeline settings UI https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch
Incorrect, that article states that is the case if "When you set a variable with the same name in multiple scopes, the following precedence appliies"...key word here SAME NAME. Thats not what this question is asking.
This is specially the case in which you want the precedence to take effect. If they are named differently, there is no need of preference. The answer from crymo99 is correct. Double checked from here: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#expansion-of-variables
This is specially the case in which you want the precedence to take effect. If they are named differently, there is no need of preference. The answer from crymo99 is correct. Double checked from here: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#expansion-of-variables
Variable scopes In the YAML file, you can set a variable at various scopes: At the root level, to make it available to all jobs in the pipeline. At the stage level, to make it available only to a specific stage. At the job level, to make it available only to a specific job. When a variable is defined at the top of a YAML, it will be available to all jobs and stages in the pipeline and is a global variable. Global variables defined in a YAML are not visible in the pipeline settings UI. Variables at the job level override variables at the root and stage level. Variables at the stage level override variables at the root level.
correct
In the YAML file, you can set a variable at various scopes: At the root level, to make it available to all jobs in the pipeline. At the stage level, to make it available only to a specific stage. At the job level, to make it available only to a specific job.
GTP: The task scope is a valid scope for defining variables in Azure Pipelines, and it has the highest precedence among all scopes. So, it is definitely a valid choice for defining variables.
Variables defined at the task scope have the highest precedence and will override any variables with the same name defined at lower scopes. Variables defined at the job scope will override any variables with the same name defined at the stage, pipeline settings UI, or pipeline root scopes. Variables defined at the stage scope will override any variables with the same name defined at the pipeline settings UI or pipeline root scopes. Finally, variables defined at the pipeline settings UI scope will override any variables with the same name defined at the pipeline root scope.
I checked and the code below gives na error. Task can't accept property variables. task: variables: string: string # Name/value pairs
In Azure Pipelines, you can define variables at four different scopes: pipeline root, pipeline settings UI, stage, and job. The precedence of these variables from highest to lowest is as follows: e. task b. job a. stage c. pipeline settings UI d. pipeline root
Variables defined at the task scope have the highest precedence and will override any variables with the same name defined at lower scopes. Variables defined at the job scope will override any variables with the same name defined at the stage, pipeline settings UI, or pipeline root scopes. Variables defined at the stage scope will override any variables with the same name defined at the pipeline settings UI or pipeline root scopes. Finally, variables defined at the pipeline settings UI scope will override any variables with the same name defined at the pipeline root scope.
I checked and the code below gives na error. Task can't accept property variables. task: variables: string: string # Name/value pairs
I checked and the code below gives na error. Task can't accept property variables. task: variables: string: string # Name/value pairs
I checked and the code below gives na error. Task can't accept property variables. task: variables: string: string # Name/value pairs