Definire le variabili

Nel caso più comune, impostare le variabili e usarle all'interno del file YAML. Questo approccio consente di tenere traccia delle modifiche apportate alla variabile nel sistema di controllo della versione. È anche possibile definire le variabili nell'interfaccia utente delle impostazioni della pipeline (vedere la scheda Classica) e farvi riferimento in YAML.

Nell'esempio seguente viene illustrato come impostare due variabili configuration e platforme usarle più avanti nei passaggi. Per usare una variabile all'interno di un'istruzione YAML, racchiuderla in $(). Non è possibile usare le variabili per definire un oggetto repository in un'istruzione YAML.

# Set variables once
variables:
  configuration: debug
  platform: x64

steps:

# Use them once
- task: MSBuild@1
  inputs:
    solution: solution1.sln
    configuration: $(configuration) # Use the variable
    platform: $(platform)

# Use them again
- task: MSBuild@1
  inputs:
    solution: solution2.sln
    configuration: $(configuration) # Use the variable
    platform: $(platform)

Ambiti delle variabili

Nel file YAML impostare una variabile in vari ambiti:

• A livello di root, per renderlo disponibile per tutti i lavori nella pipeline.
• A livello di stadio, per renderlo disponibile solo per uno stadio specifico.
• A livello di lavoro, per renderlo disponibile solo per un lavoro specifico.

Quando si definisce una variabile all'inizio di un YAML, la variabile è disponibile per tutti i processi e le fasi della pipeline ed è una variabile globale. Le variabili globali definite in un YAML non sono visibili nell'interfaccia utente delle impostazioni della pipeline.

Le variabili a livello di job sostituiscono le variabili a livello radice e di fase di lavorazione. Le variabili a livello di fase eseguono l'override delle variabili a livello radice.

variables:
  global_variable: value    # this is available to all jobs

jobs:
- job: job1
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    job_variable1: value1    # this is only available in job1
  steps:
  - bash: echo $(global_variable)
  - bash: echo $(job_variable1)
  - bash: echo $JOB_VARIABLE1 # variables are available in the script environment too

- job: job2
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    job_variable2: value2    # this is only available in job2
  steps:
  - bash: echo $(global_variable)
  - bash: echo $(job_variable2)
  - bash: echo $GLOBAL_VARIABLE

L'output di entrambi i processi ha il seguente aspetto:

# job1
value 
value1
value1

# job2
value
value2
value

Specificare le variabili

Negli esempi precedenti la variables parola chiave è seguita da un elenco di coppie chiave-valore. Le chiavi sono i nomi delle variabili e i valori sono i valori delle variabili.

Un'altra sintassi è utile quando si vogliono usare modelli per variabili o gruppi di variabili.

Usando i modelli, è possibile definire le variabili in un file YAML e includerle in un altro file YAML.

I gruppi di variabili sono un set di variabili che è possibile usare in più pipelines. Usando i gruppi di variabili, è possibile gestire e organizzare variabili comuni a varie fasi in un'unica posizione.

Usare questa sintassi per i modelli di variabili e i gruppi di variabili a livello radice di una pipeline.

In questa sintassi alternativa, la variables parola chiave accetta un elenco di identificatori di variabile. Gli identificatori di variabile sono name per una variabile regolare, group per un gruppo di variabili e template per includere un modello di variabile. Nell'esempio seguente vengono illustrati tutti e tre.

variables:
# a regular variable
- name: myvariable
  value: myvalue
# a variable group
- group: myvariablegroup
# a reference to a variable template
- template: myvariabletemplate.yml

Per altre informazioni, vedere Riutilizzo delle variabili con i modelli.

Accedi alle variabili tramite l'ambiente

Si noti che le variabili vengono rese disponibili anche agli script tramite variabili di ambiente. La sintassi per l'uso di queste variabili di ambiente dipende dal linguaggio di scripting.

Il nome è maiuscolo e . viene sostituito con _. Questa operazione viene inserita automaticamente nell'ambiente di processo. Di seguito sono riportati alcuni esempi.

• Script batch: %VARIABLE_NAME%
• Script di PowerShell: $env:VARIABLE_NAME
• Script Bash: $VARIABLE_NAME

Usando l'interfaccia della riga di comando di Azure DevOps, è possibile creare e aggiornare le variabili per le esecuzioni della pipeline nel project. È anche possibile eliminare le variabili se non sono più necessarie.

Creare una variabile Aggiornare una variabile | Eliminare una variabile |

Prerequisiti

• Installare l'estensione dell'interfaccia della riga di comando di Azure DevOps come descritto in Primi passi con l'interfaccia della riga di comando di Azure DevOps.
• Accedere a Azure DevOps usando az login.
• Impostare l'organizzazione predefinita per gli esempi in questo articolo usando az devops configure --defaults organization=YourOrganizationURL.

Creazione di una variabile

Creare variabili nella pipeline usando il comando az pipelines variable create. Per iniziare, vedere Inizia con l'interfaccia della riga di comando di Azure DevOps.

az pipelines variable create --name
                             [--allow-override {false, true}]
                             [--org]
                             [--pipeline-id]
                             [--pipeline-name]
                             [--project]
                             [--secret {false, true}]
                             [--value]

Parametri

• name: obbligatorio. Nome della variabile.
• allow-override: è facoltativo. Impostare su true se si vuole consentire l'impostazione del valore in fase di coda; in caso contrario, impostare su false.
• org: URL dell'organizzazione Azure DevOps. Configurare l'organizzazione predefinita usando az devops configure -d organization=ORG_URL. Obbligatorio se non è configurato come predefinito o prelevato tramite git config. Esempio: --org https://dev.azure.com/MyOrganizationName/.
• pipeline-id: obbligatorio se pipeline-name non viene specificato. ID della pipeline.
• pipeline-name: obbligatorio se pipeline-id non viene fornito, ma ignorato se viene specificato pipeline-id . Nome della pipeline.
• project: nome o ID del project. Configurare il project predefinito usando az devops configure -d project=NAME_OR_ID. Obbligatorio se non è configurato come predefinito o prelevato tramite git config.
• secret: facoltativo. Impostare su true se il valore della variabile è un segreto; in caso contrario, impostare su false.
• value: obbligatorio per la variabile non segreta. Valore della variabile. Per le variabili segrete, se non si specifica il parametro value , il valore viene selezionato da una variabile di ambiente preceduta AZURE_DEVOPS_EXT_PIPELINE_VAR_ da o viene richiesto di immetterlo tramite input standard. Ad esempio, una variabile denominata MySecret può essere immessa usando la variabile di ambiente AZURE_DEVOPS_EXT_PIPELINE_VAR_MySecret.

Esempio

Il comando seguente crea una variabile in MyFirstProject denominata Configuration con il valore platform nella pipeline con ID 12. Mostra il risultato in formato tabella.

az pipelines variable create --name Configuration --pipeline-id 12 --value platform --project MyFirstProject --output table

Name        Allow Override    Is Secret    Value
----------  ----------------  -----------  --------
Configuration  False             False        platform

Aggiornare una variabile

Usare il comando az pipelines variable update per aggiornare le variabili nella pipeline. Per iniziare, vedere Introduzione alla CLI di Azure DevOps.

az pipelines variable update --name
                             [--allow-override {false, true}]
                             [--new-name]
                             [--org]
                             [--pipeline-id]
                             [--pipeline-name]
                             [--project]
                             [--prompt-value {false, true}]
                             [--secret {false, true}]
                             [--value]

Parametri

• name: obbligatorio. Nome originale della variabile.
• allow-override: facoltativo. Impostare su true se si vuole consentire l'impostazione del valore in fase di coda; in caso contrario, impostare su false.
• new-name: facoltativo. Specificare per modificare il nome della variabile.
• org: URL dell'organizzazione Azure DevOps. Configurare l'organizzazione predefinita usando az devops configure -d organization=ORG_URL. Obbligatorio se non è configurato come predefinito o prelevato tramite git config. Esempio: --org https://dev.azure.com/MyOrganizationName/.
• pipeline-id: obbligatorio se pipeline-name non viene specificato. ID della pipeline.
• pipeline-name: obbligatorio se pipeline-id non viene fornito, ma ignorato se viene specificato pipeline-id . Nome della pipeline.
• project: nome o ID del project. Configurare il project predefinito usando az devops configure -d project=NAME_OR_ID. Obbligatorio se non è configurato come predefinito o prelevato tramite git config.
• prompt-value: impostare su true per aggiornare il valore di una variabile segreta usando la variabile d'ambiente o il prompt tramite input standard. I valori accettati sono false e true.
• secret: indica se il valore della variabile è un segreto. I valori accettati sono false e true.
• value: aggiorna il valore della variabile. Per le variabili segrete, utilizzare il parametro prompt-value per essere invitati a inserirlo tramite input standard. Per le console non interattive, è possibile selezionarla dalla variabile di ambiente preceduta AZURE_DEVOPS_EXT_PIPELINE_VAR_da . Ad esempio, una variabile denominata MySecret può essere inserita usando la variabile di ambiente AZURE_DEVOPS_EXT_PIPELINE_VAR_MySecret.

Esempio

Il comando seguente aggiorna la variabile di configurazione con il nuovo valore config.debug nella pipeline con ID 12. Specifica che la variabile non è un segreto e mostra il risultato in formato tabella.

az pipelines variable update --name Configuration --pipeline-id 12 --secret false --value config.debug --output table

Name           Allow Override    Is Secret    Value
-------------  ----------------  -----------  ------------
Configuration  False             False        config.debug

Eliminare una variabile

È possibile eliminare le variabili nella pipeline con il comando az pipelines variable delete. Per iniziare, vedere Introduzione alla CLI di Azure DevOps.

az pipelines variable delete --name
                             [--org]
                             [--pipeline-id]
                             [--pipeline-name]
                             [--project]
                             [--yes]

Parametri

• name: obbligatorio. Nome della variabile da eliminare.
• org: URL dell'organizzazione Azure DevOps. Configurare l'organizzazione predefinita usando az devops configure -d organization=ORG_URL. Obbligatorio se non è configurato come predefinito o prelevato tramite git config. Esempio: --org https://dev.azure.com/MyOrganizationName/.
• pipeline-id: obbligatorio se pipeline-name non viene specificato. ID della pipeline.
• pipeline-name: obbligatorio se pipeline-id non viene fornito, ma ignorato se viene specificato pipeline-id . Nome della pipeline.
• project: nome o ID del project. Configurare il project predefinito usando az devops configure -d project=NAME_OR_ID. Obbligatorio se non è configurato come predefinito o prelevato tramite git config.
• Sì: facoltativo. Indica che non è richiesta la conferma.

Esempio

Il comando seguente elimina la variabile di configurazione dalla pipeline con ID 12 e non richiede conferma.

az pipelines variable delete --name Configuration --pipeline-id 12 --yes

Deleted variable 'Configuration' successfully.

I comandi CLI di Azure DevOps non sono supportati per Azure DevOps Server.

Non impostare le variabili segrete nel file YAML. I sistemi operativi spesso registrano i comandi per i processi eseguiti e non si vuole che il log includa un segreto passato come input. Usare l'ambiente dello script o mappare la variabile all'interno del blocco variables per passare segreti alla pipeline.

È necessario impostare le variabili segrete nell'interfaccia delle impostazioni della pipeline per la pipeline. Queste variabili hanno come ambito la pipeline in cui sono impostate. È anche possibile impostare le variabili segrete nei gruppi di variabili.

Per impostare i segreti nell'interfaccia Web, seguire questa procedura:

1. Passare alla pagina Pipelines, selezionare la pipeline appropriata e quindi selezionare Edit.
2. Individuare le Variabili per questa pipeline.
3. Aggiungere o aggiornare la variabile.
4. Selezionare l'opzione Mantieni questo valore segreto per archiviare la variabile in modo crittografato.
5. Salvare la pipeline.

Le variabili segrete vengono crittografate quando sono inattive con una chiave RSA a 2048 bit. I segreti sono disponibili nell'agente per le attività e gli script da utilizzare. Fai attenzione a chi ha l'accesso per modificare la tua pipeline.

A differenza di una variabile normale, non vengono decrittografati automaticamente nelle variabili di ambiente per gli script. È necessario eseguire il mapping esplicito delle variabili segrete.

L'esempio seguente illustra come eseguire il mapping e usare una variabile segreta denominata mySecret negli script di PowerShell e Bash. Vengono definite due variabili globali. GLOBAL_MYSECRET viene assegnato il valore di una variabile mySecretsegreta e GLOBAL_MY_MAPPED_ENV_VAR viene assegnato il valore di una variabile nonSecretVariablenon segreta . A differenza di una variabile di pipeline normale, non esiste alcuna variabile di ambiente denominata MYSECRET.

L'attività di PowerShell esegue uno script per stampare le variabili.

• $(mySecret): si tratta di un riferimento diretto alla variabile segreta e funziona.
• $env:MYSECRET: tenta di accedere alla variabile segreta come variabile di ambiente, che non funziona perché le variabili segrete non vengono mappate automaticamente alle variabili di ambiente.
• $env:GLOBAL_MYSECRET: tenta di access la variabile segreta tramite una variabile globale, che non funziona anche perché le variabili segrete non possono essere mappate in questo modo.
• $env:GLOBAL_MY_MAPPED_ENV_VAR: accede alla variabile non segreta tramite una variabile globale, che funziona.
• $env:MY_MAPPED_ENV_VAR: accede alla variabile segreta tramite una variabile di ambiente specifica dell'attività, che è il modo consigliato per eseguire il mapping delle variabili segrete alle variabili di ambiente.

variables:
 GLOBAL_MYSECRET: $(mySecret) # this will not work because the secret variable needs to be mapped as env
 GLOBAL_MY_MAPPED_ENV_VAR: $(nonSecretVariable) # this works because it's not a secret.

steps:

- powershell: |
    Write-Host "Using an input-macro works: $(mySecret)"
    Write-Host "Using the env var directly does not work: $env:MYSECRET"
    Write-Host "Using a global secret var mapped in the pipeline does not work either: $env:GLOBAL_MYSECRET"
    Write-Host "Using a global non-secret var mapped in the pipeline works: $env:GLOBAL_MY_MAPPED_ENV_VAR" 
    Write-Host "Using the mapped env var for this task works and is recommended: $env:MY_MAPPED_ENV_VAR"
  env:
    MY_MAPPED_ENV_VAR: $(mySecret) # the recommended way to map to an env variable

- bash: |
    echo "Using an input-macro works: $(mySecret)"
    echo "Using the env var directly does not work: $MYSECRET"
    echo "Using a global secret var mapped in the pipeline does not work either: $GLOBAL_MYSECRET"
    echo "Using a global non-secret var mapped in the pipeline works: $GLOBAL_MY_MAPPED_ENV_VAR" 
    echo "Using the mapped env var for this task works and is recommended: $MY_MAPPED_ENV_VAR"
  env:
    MY_MAPPED_ENV_VAR: $(mySecret) # the recommended way to map to an env variable

L'output di entrambe le attività nello script precedente è simile al seguente:

Using an input-macro works: ***
Using the env var directly does not work:
Using a global secret var mapped in the pipeline does not work either:
Using a global non-secret var mapped in the pipeline works: foo
Using the mapped env var for this task works and is recommended: ***

È anche possibile usare variabili segrete al di fuori degli script. Ad esempio, è possibile eseguire il mapping delle variabili segrete alle attività usando la variables definizione . Questo esempio illustra come usare le variabili segrete $(vmsUser) e $(vmsAdminPass) in un'attività di copia di file Azure.

variables:
  VMS_USER: $(vmsUser)
  VMS_PASS: $(vmsAdminPass)

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: AzureFileCopy@6
  inputs:
    SourcePath: 'my/path' # Specify the source path
    azureSubscription: 'my-subscription' # Azure subscription name
    Destination: 'AzureVMs' # Destination type
    storage: 'my-storage' # Azure storage account name
    resourceGroup: 'my-resource-group' # Resource group name
    vmsAdminUserName: $(VMS_USER) # Admin username for the VM
    vmsAdminPassword: $(VMS_PASS) # Admin password for the VM
    CleanTargetBeforeCopy: false # Do not clean the target before copying

Fare riferimento alle variabili segrete nei gruppi di variabili

Questo esempio illustra come fare riferimento a un gruppo di variabili nel file YAML e come aggiungere variabili all'interno di YAML. Nell'esempio vengono usate due variabili del gruppo di variabili: user e token. La token variabile è segreta ed è mappata alla variabile $env:MY_MAPPED_TOKEN di ambiente in modo che sia possibile farvi riferimento in YAML.

Questo YAML esegue una chiamata REST per recuperare un elenco di versioni e restituisce il risultato.

variables: 
- group: 'my-var-group' # variable group
- name: 'devopsAccount' # new variable defined in YAML
  value: 'contoso'
- name: 'projectName' # new variable defined in YAML
  value: 'contosoads'

steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
        # Encode the Personal Access Token (PAT)
        # $env:USER is a normal variable in the variable group
        # $env:MY_MAPPED_TOKEN is a mapped secret variable
        $base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $env:USER,$env:MY_MAPPED_TOKEN)))

        # Get a list of releases
        $uri = "https://vsrm.dev.azure.com/$(devopsAccount)/$(projectName)/_apis/release/releases?api-version=5.1"

        # Invoke the REST call
        $result = Invoke-RestMethod -Uri $uri -Method Get -ContentType "application/json" -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)}

        # Output releases in JSON
        Write-Host $result.value
  env:
    MY_MAPPED_TOKEN: $(token) # Maps the secret variable $(token) from my-var-group

Per impostare le variabili segrete usando l'interfaccia della riga di comando di Azure DevOps, vedere Creare una variabile o Aggiornare una variabile.

Azure DevOps i comandi CLI non sono supportati per Azure DevOps Server.

Usare gli output in un passaggio diverso

Per usare l'output da una fase diversa, usare il formato stageDependencies.STAGE.JOB.outputs['TASK.VARIABLE'] per fare riferimento alle variabili. A livello di fase, ma non a livello di lavoro, è possibile usare queste variabili nelle condizioni.

Le variabili di output sono disponibili solo nella fase downstream successiva. Se più fasi utilizzano la stessa variabile di output, usare la dependsOn condizione .

stages:
- stage: One
  jobs:
  - job: A
    steps:
    - task: MyTask@1  # this step generates the output variable
      name: ProduceVar  # because we're going to depend on it, we need to name the step

- stage: Two
  dependsOn:
  - One
  jobs:
  - job: B
    variables:
      # map the output variable from A into this job
      varFromA: $[ stageDependencies.One.A.outputs['ProduceVar.MyVar'] ]
    steps:
    - script: echo $(varFromA) # this step uses the mapped-in variable

- stage: Three
  dependsOn:
  - One
  - Two
  jobs:
  - job: C
    variables:
      # map the output variable from A into this job
      varFromA: $[ stageDependencies.One.A.outputs['ProduceVar.MyVar'] ]
    steps:
    - script: echo $(varFromA) # this step uses the mapped-in variable

È anche possibile passare variabili tra le fasi usando un input di file. Per farlo, è necessario definire le variabili nella seconda fase a livello di job e quindi passare le variabili come input env:.

## script-a.sh
echo "##vso[task.setvariable variable=sauce;isOutput=true]crushed tomatoes"

## script-b.sh
echo 'Hello file version'
echo $skipMe
echo $StageSauce

## azure-pipelines.yml
stages:

- stage: one
  jobs:
  - job: A
    steps:
    - task: Bash@3
      inputs:
          filePath: 'script-a.sh'
      name: setvar
    - bash: |
       echo "##vso[task.setvariable variable=skipsubsequent;isOutput=true]true"
      name: skipstep

- stage: two
  jobs:
  - job: B
    variables:
      - name: StageSauce
        value: $[ stageDependencies.one.A.outputs['setvar.sauce'] ]
      - name: skipMe
        value: $[ stageDependencies.one.A.outputs['skipstep.skipsubsequent'] ]
    steps:
    - task: Bash@3
      inputs:
        filePath: 'script-b.sh'
      name: fileversion
      env:
        StageSauce: $(StageSauce) # predefined in variables section
        skipMe: $(skipMe) # predefined in variables section
    - task: Bash@3
      inputs:
        targetType: 'inline'
        script: |
          echo 'Hello inline version'
          echo $(skipMe) 
          echo $(StageSauce) 

L'output delle fasi della pipeline precedente è simile al seguente:

Hello inline version
true
crushed tomatoes

Non esiste alcun comando az pipelines che si applica all'uso di variabili di output dalle attività.

I comandi CLI di Azure DevOps non sono supportati per Azure DevOps Server.

Impostare una variabile con ambito di attività tramite uno script

Per impostare una variabile da uno script, usare il task.setvariablecomando di registrazione. Questo comando aggiorna le variabili di ambiente per i processi successivi. Le attività successive possono accedere alla nuova variabile usando la sintassi macro e all'interno delle attività come variabili di ambiente.

Quando si imposta su issecret true, il valore della variabile viene salvato come segreto e mascherato dal log. Per altre informazioni sulle variabili segrete, vedere Comandi di registrazione.

steps:
# Create a variable
- bash: |
    echo "##vso[task.setvariable variable=sauce]crushed tomatoes" # remember to use double quotes

# Use the variable
# "$(sauce)" is replaced by the contents of the `sauce` variable by Azure Pipelines
# before handing the body of the script to the shell.
- bash: |
    echo my pipeline variable is $(sauce)

I passaggi successivi aggiungono la variabile della pipeline al loro ambiente. Non è possibile usare la variabile nel passaggio definito.

steps:
# Create a variable
# Note that this does not update the environment of the current script.
- bash: |
    echo "##vso[task.setvariable variable=sauce]crushed tomatoes"

# An environment variable called `SAUCE` has been added to all downstream steps
- bash: |
    echo "my environment variable is $SAUCE"
- pwsh: |
    Write-Host "my environment variable is $env:SAUCE"

Output della pipeline precedente.

my environment variable is crushed tomatoes
my environment variable is crushed tomatoes

Impostare una variabile di output multi-lavoro

Se si vuole rendere disponibile una variabile per i processi futuri, è necessario contrassegnarla come variabile di output usando isOutput=true. È quindi possibile eseguirne il mapping in processi futuri usando la $[] sintassi e includendo il nome del passaggio che imposta la variabile. Le variabili di output multi-job funzionano solo per i job nella stessa fase.

Per trasmettere variabili ai processi in fasi diverse, usare la sintassi delle dipendenze di fase.

Quando si crea una variabile di output multi-attività, è necessario assegnare l'espressione a una variabile. In questo YAML, $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] viene assegnato alla variabile $(myVarFromJobA).

jobs:
# Set an output variable from job A
- job: A
  pool:
    vmImage: 'windows-latest'
  steps:
  - powershell: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the value"
    name: setvarStep
  - script: echo $(setvarStep.myOutputVar)
    name: echovar

# Map the variable into job B
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromJobA: $[ dependencies.A.outputs['setvarStep.myOutputVar'] ]  # map in the variable
                                                                          # remember, expressions require single quotes
  steps:
  - script: echo $(myVarFromJobA)
    name: echovar

Output della pipeline precedente.

this is the value
this is the value

Se si imposta una variabile da una fase a un'altra, usare stageDependencies.

stages:
- stage: A
  jobs:
  - job: A1
    steps:
     - bash: echo "##vso[task.setvariable variable=myStageOutputVar;isOutput=true]this is a stage output var"
       name: printvar

- stage: B
  dependsOn: A
  variables:
    myVarfromStageA: $[ stageDependencies.A.A1.outputs['printvar.myStageOutputVar'] ]
  jobs:
  - job: B1
    steps:
    - script: echo $(myVarfromStageA)

Se imposti una variabile da un matrix o slice, è necessario fare riferimento alla variabile quando la si accede in un lavoro a valle, includendo:

• Il nome del lavoro.
• Il passo.

jobs:

# Set an output variable from a job with a matrix
- job: A
  pool:
    vmImage: 'ubuntu-latest'
  strategy:
    maxParallel: 2
    matrix:
      debugJob:
        configuration: debug
        platform: x64
      releaseJob:
        configuration: release
        platform: x64
  steps:
  - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the $(configuration) value"
    name: setvarStep
  - bash: echo $(setvarStep.myOutputVar)
    name: echovar

# Map the variable from the debug job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromJobADebug: $[ dependencies.A.outputs['debugJob.setvarStep.myOutputVar'] ]
  steps:
  - script: echo $(myVarFromJobADebug)
    name: echovar

jobs:

# Set an output variable from a job with slicing
- job: A
  pool:
    vmImage: 'ubuntu-latest'
    parallel: 2 # Two slices
  steps:
  - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the slice $(system.jobPositionInPhase) value"
    name: setvarStep
  - script: echo $(setvarStep.myOutputVar)
    name: echovar

# Map the variable from the job for the first slice
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromJobsA1)"
    name: echovar

Assicurarsi di anteporre il nome del processo alle variabili di output di un processo di distribuzione . In questo caso, il nome del processo è A:

jobs:

# Set an output variable from a deployment
- deployment: A
  pool:
    vmImage: 'ubuntu-latest'
  environment: staging
  strategy:
    runOnce:
      deploy:
        steps:
        - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - bash: echo $(setvarStep.myOutputVar)
          name: echovar

# Map the variable from the job for the first slice
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['A.setvarStep.myOutputVar'] ]
  steps:
  - bash: "echo $(myVarFromDeploymentJob)"
    name: echovar

Non esiste alcun comando az pipelines applicabile all'impostazione delle variabili negli script.

I comandi CLI di Azure DevOps non sono supportati per Azure DevOps Server.

È possibile impostare una variabile usando un'espressione. Si è già riscontrato un caso di questo approccio quando si imposta una variabile sull'output di un'altra variabile da un processo precedente.

- job: B
  dependsOn: A
  variables:
    myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ] # remember to use single quotes

È possibile usare una qualsiasi delle espressioni supportate per impostare una variabile. Di seguito è riportato un esempio di impostazione di una variabile da usare come contatore che inizia da 100, viene incrementato di 1 per ogni esecuzione e viene reimpostato su 100 ogni giorno.

jobs:
- job:
  variables:
    a: $[counter(format('{0:yyyyMMdd}', pipeline.startTime), 100)]
  steps:
  - bash: echo $(a)

Per altre informazioni su contatori, dipendenze e altre espressioni, vedere espressioni.

Non esiste alcun comando az pipelines applicabile all'impostazione delle variabili tramite espressioni.

I comandi CLI di Azure DevOps non sono supportati per Azure DevOps Server.

Se una variabile viene visualizzata nel variables blocco di un file YAML, il relativo valore è fisso e gli utenti non possono eseguirne l'override in fase di coda. Definire le variabili in un file YAML, ma in alcuni casi questo approccio non ha senso. Ad esempio, è possibile definire una variabile privata e non esporla nel file YAML. In alternativa, potrebbe essere necessario impostare manualmente un valore di variabile durante l'esecuzione della pipeline.

Esistono due opzioni per definire i valori di tempo della coda. È possibile definire una variabile nell'interfaccia utente e selezionare l'opzione Consenti agli utenti di sovrascrivere questo valore durante l'esecuzione di questa pipeline oppure usare parametri di runtime. Se la tua variabile non è un segreto, è consigliabile usare parametri runtime.

Per impostare una variabile in fase di coda, aggiungere una nuova variabile all'interno della pipeline e selezionare l'opzione di override. Solo gli utenti con l'autorizzazione Modifica configurazione della coda di compilazione possono cambiare il valore di una variabile.

Per consentire l'impostazione di una variabile in fase di coda, assicurarsi che la variabile non venga visualizzata anche nel variables blocco di una pipeline o di un processo. Se si definisce una variabile sia nel blocco di variabili di un YAML che nell'interfaccia utente, il valore in YAML ha priorità.

Per maggiore sicurezza, usare un set predefinito di valori per variabili settable in fase di coda e tipi sicuri, ad esempio valori booleani e numeri interi. Per le stringhe, usare un set predefinito di valori.

Per scegliere quali variabili possono essere impostate in fase di coda usando l'interfaccia della riga di comando di DevOps Azure, vedere Creare una variabile o Aggiornare una variabile.

I comandi CLI di Azure DevOps non sono supportati per Azure DevOps Server.

Quando si imposta una variabile con lo stesso nome in più ambiti, viene applicata la precedenza seguente (precedenza più alta):

1. Variabile a livello di lavoro impostata nel file YAML
2. Variabile a livello di fase impostata nel file YAML
3. Variabile a livello di pipeline impostata nel file YAML
4. Variabile impostata nel tempo di attesa
5. Variabile pipeline impostata nell'interfaccia utente delle impostazioni della pipeline

Nell'esempio seguente la stessa variabile viene impostata a a livello di pipeline e di processo nel file YAML. Viene anche impostato in un gruppo Gdi variabili e come variabile nell'interfaccia utente delle impostazioni della pipeline.

variables:
  a: 'pipeline yaml'

stages:
- stage: one
  displayName: one
  variables:
  - name: a
    value: 'stage yaml'

  jobs:
  - job: A
    variables:
    - name: a
      value: 'job yaml'
    steps:
    - bash: echo $(a)        # This will be 'job yaml'

Quando si imposta una variabile con lo stesso nome nello stesso ambito, l'ultimo valore impostato ha la precedenza.

stages:
- stage: one
  displayName: Stage One
  variables: 
    - name: a
      value: alpha
    - name: a
      value: beta
  jobs: 
  - job: I
    displayName: Job I
    variables:
      - name: b
        value: uno
      - name: b
        value: dos
    steps: 
    - script: echo $(a) #outputs beta
    - script: echo $(b) #outputs dos

Le variabili vengono espanse una volta all'avvio dell'esecuzione e di nuovo all'inizio di ogni passaggio. Ad esempio:

jobs:
- job: A
  variables:
    a: 10
  steps:
  - bash: |
      echo $(a)            # This will be 10
      echo '##vso[task.setvariable variable=a]20'
      echo $(a)            # This will also be 10, since the expansion of $(a) happens before the step
  - bash: echo $(a)        # This will be 20, since the variables are expanded just before the step

Nell'esempio precedente sono presenti due passaggi. L'espansione di $(a) si verifica una volta all'inizio del processo e una volta all'inizio di ognuno dei due passaggi.

Poiché le variabili vengono espanse all'inizio di un processo, non è possibile usarle in una strategia. Nell'esempio seguente non è possibile usare la variabile a per espandere la matrice del processo, perché la variabile è disponibile solo all'inizio di ogni processo espanso.

jobs:
- job: A
  variables:
    a: 10
  strategy:
    matrix:
      x:
        some_variable: $(a)    # This does not work

Se la variabile è una variabile a di output di un processo precedente, è possibile usarla in un processo futuro.

- job: A
  steps:
  - powershell: echo "##vso[task.setvariable variable=a;isOutput=true]10"
    name: a_step

# Map the variable into job B
- job: B
  dependsOn: A
  variables:
    some_variable: $[ dependencies.A.outputs['a_step.a'] ]

Espansione ricorsiva

Nell'agente le variabili a cui si fa riferimento usando $( ) la sintassi vengono espanse in modo ricorsivo. Ad esempio:

variables:
  myInner: someValue
  myOuter: $(myInner)

steps:
- script: echo $(myOuter)  # prints "someValue"
  displayName: Variable is $(myOuter)  # display name is "Variable is someValue"

Non esiste alcun comando az pipelines che si applichi all'espansione delle variabili.

I comandi CLI di Azure DevOps non sono supportati per Azure DevOps Server.