Definieren von Variablen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Variablen stellen eine bequeme Möglichkeit dar, wichtige Bits von Daten in verschiedene Teile der Pipeline zu übernehmen. Die häufigste Verwendung von Variablen besteht darin, einen Wert zu definieren, den Sie dann in Ihrer Pipeline verwenden können. Alle Variablen sind Zeichenfolgen und veränderbar. Der Wert einer Variablen kann sich von Ausführung zu Ausführung oder Auftrag zu Auftrag Ihrer Pipeline ändern.

Wenn Sie die gleiche Variable an mehreren Stellen mit dem gleichen Namen definieren, wird die Variable mit dem lokalsten Geltungsbereich verwendet. Eine auf Auftragsebene definierte Variable kann also eine auf Phasenebene festgelegte Variable außer Kraft setzen. Eine auf Phasenebene definierte Variable setzt eine auf Pipelinestammebene festgelegte Variable außer Kraft. Ein auf Pipelinestammebene festgelegte Variable setzt eine Variable außer Kraft, die auf der Benutzeroberfläche für die Pipelineeinstellungen festgelegt wurde. Weitere Informationen zum Arbeiten mit Variablen, die auf Auftrags-, Phasen- und Stammebene definiert sind, finden Sie unter Variablenbereich.

Sie können Variablen mit Ausdrücken verwenden, um Werte bedingt zuzuweisen und Pipelines weiter anzupassen.

Variablen unterscheiden sich von Laufzeitparametern. Laufzeitparameter sind typisiert und während der Analyse der Vorlage verfügbar.

Benutzerdefinierte Variablen

Wenn Sie eine Variable definieren, können Sie unterschiedliche Syntaxvarianten (Makro, Vorlagenausdruck oder Runtime) verwenden. Die verwendete Syntax bestimmt, wo in der Pipeline die Variable gerendert wird.

In YAML-Pipelines können Variablen auf Stamm-, Phasen- und Auftragsebene festgelegt werden. Außerdem können Sie Variablen außerhalb einer YAML-Pipeline über die Benutzeroberfläche angeben. Wenn Sie eine Variable über die Benutzeroberfläche festlegen, kann diese Variable verschlüsselt und als Geheimnis festgelegt werden.

Benutzerdefinierte Variablen können als schreibgeschützt festgelegt werden. Es gibt Einschränkungen bei Variablennamen. Beispielsweise dürfen Variablennamen nicht mit secret beginnen.

Sie können eine Variablengruppe verwenden, um Variablen über mehrere Pipelines hinweg verfügbar zu machen.

Verwenden Sie Vorlagen, um Variablen, die in mehreren Pipelines verwendet werden, in einer einzelnen Datei zu definieren.

Benutzerdefinierte mehrzeilige Variablen

Azure DevOps unterstützt mehrzeilige Variablen, es gibt allerdings gewisse Einschränkungen.

Downstreamkomponenten wie Pipelineaufgaben verarbeiten die Variablenwerte möglicherweise nicht ordnungsgemäß.

Azure DevOps ändert keine benutzerdefinierten Variablenwerte. Variablenwerte müssen ordnungsgemäß formatiert werden, bevor sie als mehrzeilige Variablen übergeben werden. Verzichten Sie beim Formatieren ihrer Variablen auf Sonderzeichen, verwenden Sie keine eingeschränkten Namen, und achten Sie darauf, ein Zeilenabschlussformat zu verwenden, das für das Betriebssystem Ihres Agents geeignet ist.

Mehrzeilige Variablen verhalten sich je nach Betriebssystem unterschiedlich. Formatieren Sie mehrzeilige Variablen ordnungsgemäß für das Zielbetriebssystem, um dies zu vermeiden.

Azure DevOps ändert niemals Variablenwerte, auch wenn Sie eine nicht unterstützte Formatierung bereitstellen.

Systemvariablen

Zusätzlich zu benutzerdefinierten Variablen verfügt Azure Pipelines über Systemvariablen mit vordefinierten Werten. Die vordefinierte Variable Build.BuildId gibt z. B. die ID der einzelnen Builds an und kann zur Identifizierung verschiedener Pipelineausführungen verwendet werden. Sie können die Variable Build.BuildId in Skripts oder Aufgaben verwenden, wenn Sie einen eindeutigen Wert benötigen.

Wenn Sie YAML-Pipelines oder klassische Buildpipelines verwenden, finden Sie unter Verwenden vordefinierter Variablen eine umfassende Liste der Systemvariablen.

Wenn Sie klassische Releasepipelines verwenden, finden Sie weitere Informationen unter Klassische Release- und Artefaktvariablen.

Systemvariablen werden mit ihrem aktuellen Wert festgelegt, wenn Sie die Pipeline ausführen. Einige Variablen werden automatisch festgelegt. Als Pipelineersteller*in oder Endbenutzer*in ändern Sie den Wert einer Systemvariablen, bevor die Pipeline ausgeführt wird.

Systemvariablen sind schreibgeschützt.

Umgebungsvariablen

Umgebungsvariablen sind spezifische Variablen für das verwendete Betriebssystem. Sie werden auf plattformspezifische Weise in eine Pipeline eingefügt. Das Format entspricht der Formatierung von Umgebungsvariablen für Ihre spezifische Skriptplattform.

Auf UNIX-Systemen (macOS und Linux) haben Umgebungsvariablen das Format $NAME. Unter Windows wird für Batch das Format %NAME% und in PowerShell das Format $env:NAME verwendet.

Systemvariablen und benutzerdefinierte Variablen werden auch als Umgebungsvariablen für Ihre Plattform eingefügt. Wenn Variablen in Umgebungsvariablen konvertiert werden, werden Variablennamen groß geschrieben, und Punkte werden in Unterstriche umgewandelt. So wird beispielsweise der Variablenname any.variable zum Variablennamen $ANY_VARIABLE.

Es gibt Einschränkungen bei Variablennamen für Umgebungsvariablen. Beispielsweise dürfen Variablennamen nicht mit secret beginnen.

Einschränkungen bei Variablennamen

Benutzerdefinierte Variablen und Umgebungsvariablen können Buchstaben und Zahlen sowie die Zeichen . und _ enthalten. Verwenden Sie keine vom System reservierten Variablenpräfixe. Diese sind: endpoint, input, secret, path und securefile. Jede Variable, die mit einer dieser Zeichenfolgen beginnt (unabhängig von der Groß-/Kleinschreibung), steht für Ihre Aufgaben und Skripts nicht zur Verfügung.

Grundlegendes zur Variablensyntax

Azure Pipelines unterstützt drei verschiedene Methoden, um auf Variablen zu verweisen: Makro, Vorlagenausdruck und Laufzeitausdruck. Die einzelnen Syntaxvarianten können jeweils für einen anderen Zweck verwendet werden. Hierbei gelten allerdings gewisse Einschränkungen.

In einer Pipeline werden Vorlagenausdrucksvariablen (${{ variables.var }}) zur Kompilierzeit verarbeitet, bevor die Laufzeit beginnt. Makrosyntaxvariablen ($(var)) werden während der Laufzeit verarbeitet, bevor eine Aufgabe ausgeführt wird. Laufzeitausdrücke ($[variables.var]) werden ebenfalls während der Laufzeit verarbeitet, sind aber für die Verwendung mit Bedingungen und Ausdrücken vorgesehen. Wenn Sie einen Laufzeitausdruck verwenden, muss er die gesamte rechte Seite einer Definition einnehmen.

In diesem Beispiel sehen Sie, dass der Vorlagenausdruck nach dem Aktualisieren der Variablen immer noch den Anfangswert der Variablen besitzt. Der Wert der Makrosyntaxvariablen wird aktualisiert. Der Wert des Vorlagenausdrucks ändert sich nicht, da alle Vorlagenausdrucksvariablen zur Kompilierzeit verarbeitet werden, bevor Aufgaben ausgeführt werden. Makrosyntaxvariablen werden dagegen vor der Ausführung der jeweiligen Aufgabe ausgewertet.

variables:
- name: one
  value: initialValue 

steps:
  - script: |
      echo ${{ variables.one }} # outputs initialValue
      echo $(one)
    displayName: First variable pass
  - bash: echo "##vso[task.setvariable variable=one]secondValue"
    displayName: Set new variable value
  - script: |
      echo ${{ variables.one }} # outputs initialValue
      echo $(one) # outputs secondValue
    displayName: Second variable pass

Makrosyntaxvariablen

In den meisten Dokumentationsbeispielen wird Makrosyntax ($(var)) verwendet. Die Makrosyntax wurde entwickelt, um Variablenwerte in Aufgabeneingaben und andere Variablen einzufügen.

Variablen mit Makrosyntax werden verarbeitet, bevor eine Aufgabe während der Laufzeit ausgeführt wird. Die Laufzeit folgt nach der Vorlagenerweiterung. Stößt das System auf einen Makroausdruck, ersetzt es diesen durch den Inhalt der Variablen. Wenn also keine Variable mit diesem Namen vorhanden ist, ändert sich der Makroausdruck nicht. Kann beispielsweise $(var) nicht ersetzt werden, wird $(var) durch nichts ersetzt.

Makrosyntaxvariablen bleiben unverändert ohne Wert, da ein leerer Wert wie $() ggf. eine Bedeutung für die von Ihnen ausgeführte Aufgabe hat und der Agent nicht davon ausgehen sollte, dass dieser Wert ersetzt werden soll. Wenn Sie beispielsweise $(foo) verwenden, um auf die Variable foo in einer Bash-Aufgabe zu verweisen, funktionieren Ihre Bash-Skripts möglicherweise nicht mehr, wenn alle $()-Ausdrücke in der Eingabe für die Aufgabe ersetzt werden.

Makrovariablen werden nur erweitert, wenn sie nicht als Schlüsselwort, sondern für einen Wert verwendet werden. Werte werden auf der rechten Seite einer Pipelinedefinition angezeigt. Folgendes ist gültig: key: $(value). Folgendes ist nicht gültig: $(key): value. Makrovariablen werden nicht erweitert, wenn sie zur Inlineanzeige eines Auftragsnamens verwendet werden. Verwenden Sie stattdessen die displayName-Eigenschaft.

Hinweis

Makrosyntaxvariablen werden nur für stages, jobs und steps erweitert. Sie können z. B. keine Makrosyntax innerhalb einer Ressource resource or trigger verwenden.

In diesem Beispiel wird Makrosyntax mit Bash, PowerShell und einer Skriptaufgabe verwendet. Die Syntax zum Aufrufen einer Variablen mit Makrosyntax ist für alle drei identisch:

variables:
 - name: projectName
   value: contoso

steps: 
- bash: echo $(projectName)
- powershell: echo $(projectName)
- script: echo $(projectName)

Syntax für Vorlagenausdrücke

Die Syntax für Vorlagenausdrücke kann sowohl zum Erweitern von Vorlagenparametern als auch zum Erweitern von Variablen (${{ variables.var }}) verwendet werden. Vorlagenvariablen werden zur Kompilierzeit verarbeitet und vor Beginn der Laufzeit ersetzt. Vorlagenausdrücke ermöglichen es, Teile des YAML-Codes als Vorlagen wiederzuverwenden.

Vorlagenvariablen werden automatisch zu leeren Zeichenfolgen zusammengefügt, wenn kein Ersatzwert gefunden wird. Vorlagenausdrücke können im Gegensatz zu Makro- und Laufzeitausdrücken entweder als Schlüssel (linke Seite) oder als Werte (rechte Seite) angezeigt werden. Folgendes ist gültig: ${{ variables.key }} : ${{ variables.value }}.

Syntax für Laufzeitausdrücke

Die Syntax für Laufzeitausdrücke kann für Variablen verwendet werden, die zur Laufzeit erweitert werden ($[variables.var]). Laufzeitausdruckvariablen werden automatisch zu leeren Zeichenfolgen zusammengefügt, wenn kein Ersatzwert gefunden wird. Verwenden Sie Laufzeitausdrücke in Auftragsbedingungen, um die bedingte Ausführung von Aufträgen oder ganzen Phasen zu unterstützen.

Laufzeitausdrucksvariablen werden nur erweitert, wenn sie nicht als Schlüsselwort, sondern für einen Wert verwendet werden. Werte werden auf der rechten Seite einer Pipelinedefinition angezeigt. Folgendes ist gültig: key: $[variables.value]. Folgendes ist nicht gültig: $[variables.key]: value. Der Laufzeitausdruck muss die gesamte rechte Seite eines Schlüssel-Wert-Paars einnehmen. key: $[variables.value] ist beispielsweise gültig, key: $[variables.value] foo dagegen nicht.

Syntax Beispiel Verarbeitungszeitpunkt Ort der Erweiterung in einer Pipelinedefinition Art des Renderings, wenn nicht gefunden
Makro $(var) Laufzeit vor der Aufgabenausführung Wert (rechte Seite) Gibt $(var) aus.
Vorlagenausdruck ${{ variables.var }} Kompilierzeit Schlüssel oder Wert (links oder rechts) Leere Zeichenfolge
Laufzeitausdruck $[variables.var] Laufzeit Wert (rechte Seite) Leere Zeichenfolge

Zu verwendende Syntax

Verwenden Sie Makrosyntax, wenn Sie Eingaben für eine Aufgabe bereitstellen.

Wählen Sie einen Laufzeitausdruck aus, wenn Sie mit Bedingungen und Ausdrücken arbeiten. Verwenden Sie jedoch keinen Laufzeitausdruck, wenn Ihre leere Variable nicht ausgegeben werden soll (Beispiel: $[variables.var]) – also etwa, wenn Sie über bedingte Logik verfügen, die darauf basiert ist, dass eine Variable einen bestimmten Wert (oder keinen Wert) hat. Verwenden Sie in diesem Fall einen Makroausdruck.

Verwenden Sie einen Vorlagenausdruck, wenn Sie eine Variable in einer Vorlage definieren.

Festlegen von Variablen in einer Pipeline

Die Variablen werden üblicherweise in der YAML-Datei festgelegt und verwendet. So können Sie auch Änderungen an der Variablen in Ihrem Versionskontrollsystem nachverfolgen. Sie können Variablen auch auf der Benutzeroberfläche für die Pipelineeinstellungen definieren (siehe Registerkarte „Klassisch“) und in Ihrem YAML-Code darauf verweisen.

Das folgende Beispiel zeigt, wie Sie zwei Variablen festlegen configuration und platform in weiteren Schritten verwenden. Umschließen Sie eine Variable mit $(), um sie in einer YAML-Anweisung zu verwenden. Variablen können nicht verwendet werden, um ein repository in einer YAML-Anweisung zu definieren.

# 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)

Variablenbereiche

In der YAML-Datei können Sie eine Variable in verschiedenen Bereichen festlegen:

  • Auf Stammebene, um sie für alle Aufträge in der Pipeline verfügbar zu machen
  • Auf Phasenebene, um sie nur für eine bestimmte Phase verfügbar zu machen
  • Auf Auftragsebene, um sie nur für einen bestimmten Auftrag verfügbar zu machen

Wenn Sie eine Variable am Anfang einer YAML-Datei definieren, ist die Variable für alle Aufträge und Phasen in der Pipeline verfügbar und eine globale Variable. Globale Variablen, die in einer YAML-Datei definiert sind, sind auf der Benutzeroberfläche für die Pipelineeinstellungen nicht sichtbar.

Variablen auf Auftragsebene setzen Variablen auf Stamm- und Phasenebene außer Kraft. Variablen auf Phasenebene setzen Variablen auf Stammebene außer Kraft.

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

Die Ausgabe beider Aufträge sieht wie folgt aus:

# job1
value 
value1
value1

# job2
value
value2
value

Angeben von Variablen

In den vorherigen Beispielen folgt auf das variables-Schlüsselwort eine Liste mit Schlüssel-Wert-Paaren. Die Schlüssel sind die Variablennamen, die Werte sind die Variablenwerte.

Es gibt eine weitere Syntax, die hilfreich ist, wenn Sie Vorlagen für Variablen oder Variablengruppen verwenden möchten.

Mithilfe von Vorlagen können Variablen in YAML-Code definiert und in eine andere YAML-Datei eingefügt werden.

Variablengruppen sind eine Reihe von Variablen, die Sie für mehrere Pipelines verwenden können. Mit ihnen können Sie Variablen, die für verschiedene Phasen gleich sind, an einem zentralen Ort verwalten und organisieren.

Verwenden Sie diese Syntax für Variablenvorlagen und Variablengruppen auf der Stammebene einer Pipeline.

In dieser alternativen Syntax akzeptiert das variables-Schlüsselwort eine Liste von Variablenbezeichnern. Die Variablenbezeichner sind name für eine reguläre Variable, group für eine Variablengruppe und template zum Einschließen einer Variablenvorlage. Im folgenden Beispiel werden alle drei veranschaulicht:

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

Weitere Informationen zur Wiederverwendung von Variablen mit Vorlagen finden Sie hier.

Zugreifen auf Variablen über die Umgebung

Beachten Sie, dass Variablen auch über Umgebungsvariablen für Skripts verfügbar gemacht werden. Die Syntax für die Verwendung dieser Umgebungsvariablen hängt von der Skriptsprache ab.

Der Name ist groß geschrieben und der . wird durch den _ ersetzt. Dies wird automatisch in die Prozessumgebung eingefügt. Im Folgenden finden Sie einige Beispiele:

  • Batchskript: %VARIABLE_NAME%
  • PowerShell-Skript: $env:VARIABLE_NAME
  • Bash-Skript: $VARIABLE_NAME

Wichtig

Vordefinierte Variablen, die Dateipfade enthalten, werden basierend auf Agent-Hosttyp und Shelltyp in das entsprechende Format umgewandelt. Unter Windows ist das „C:\foo\“. Unter Unix wird „/foo/“ verwendet. Wenn Sie Bash-Skriptaufgaben unter Windows ausführen, sollten Sie für den Zugriff auf diese Variablen nicht die Pipelinevariablenmethode, sondern die Umgebungsvariablenmethode verwenden, um die richtige Formatierung des Dateipfads sicherzustellen.

Festlegen von geheimen Variablen

Legen Sie geheime Variablen nicht in Ihrer YAML-Datei fest. Betriebssysteme protokollieren häufig Befehle für die ausgeführten Prozesse, und Sie möchten natürlich nicht, dass das Protokoll ein Geheimnis enthält, das Sie als Eingabe übergeben haben. Verwenden Sie die Umgebung des Skripts, oder ordnen Sie die Variable innerhalb des variables-Blocks zu, um Geheimnisse an Ihre Pipeline zu übergeben.

Hinweis

Azure Pipelines bemüht sich, geheime Schlüssel beim Ausgeben von Daten an Pipelineprotokolle zu maskieren, sodass möglicherweise zusätzliche Variablen und Daten in Ausgabe- und Protokollen maskiert werden, die nicht als geheime Schlüssel festgelegt sind.

Geheime Variablen müssen für Ihre Pipeline über die Benutzeroberfläche für die Pipelineeinstellungen festgelegt werden. Diese Variablen sind auf die Pipeline ausgerichtet, in der sie festgelegt sind. Sie können auch geheime Variablen in Variablengruppen festlegen.

Führen Sie die folgenden Schritte aus, um Geheimnisse über die Weboberfläche festzulegen:

  1. Wechseln Sie zur Seite Pipelines, wählen Sie die entsprechende Pipeline aus und klicken Sie dann auf Bearbeiten.
  2. Suchen Sie die Variablen für diese Pipeline.
  3. Fügen Sie die Variable hinzu oder aktualisieren Sie sie.
  4. Wählen Sie die Option Diesen Wert geheim halten, um die Variable verschlüsselt zu speichern.
  5. Speichern Sie die Pipeline.

Geheimnisvariablen werden im Ruhezustand mit einem 2048-Bit-RSA-Schlüssel verschlüsselt. Geheimnisse sind auf dem Agent für verwendbare Aufgaben und Skripts verfügbar. Achten Sie darauf, wer zum Ändern Ihrer Pipeline berechtigt ist.

Wichtig

Wir versuchen zwar, die in der Azure Pipelines-Ausgabe angezeigten Geheimnisse zu maskieren, Sie müssen aber trotzdem Vorkehrungen treffen. Geben Sie Geheimnisse niemals als Ausgabe zurück. Einige Betriebssysteme protokollieren Befehlszeilenargumente. Geben Sie niemals Geheimnisse über die Befehlszeile weiter. Stattdessen wird empfohlen, Ihre Geheimnisse Umgebungsvariablen zuzuordnen.

Wir maskieren niemals Teilzeichenfolgen von Geheimnissen. Wenn beispielsweise „abc123“ als Geheimnis festgelegt ist, wird „abc“ in den Protokollen nicht maskiert. Dadurch soll vermieden werden, dass Geheimnisse zu detailliert maskiert werden, sodass die Protokolle nicht mehr lesbar sind. Aus diesem Grund sollten Geheimnisse keine strukturierten Daten enthalten. Wenn beispielsweise „{ "foo": "bar" }“ als Geheimnis festgelegt ist, wird „bar“ nicht in den Protokollen maskiert.

Im Gegensatz zu einer normalen Variablen werden sie nicht automatisch zu Umgebungsvariablen für Skripts entschlüsselt. Geheime Variablen müssen explizit zugeordnet werden.

Im folgenden Beispiel wird gezeigt, wie eine geheime Variable mit dem Namen mySecret in PowerShell- und Bash-Skripts zugeordnet und verwendet wird. Es werden zwei globale Variablen definiert. GLOBAL_MYSECRET wird dem Wert einer geheimen Variablen mySecret und GLOBAL_MY_MAPPED_ENV_VAR wird dem Wert einer nicht geheimen Variablen nonSecretVariable zugewiesen. Anders als bei einer normalen Pipelinevariablen gibt es keine Umgebungsvariable namens MYSECRET.

Die PowerShell-Aufgabe führt ein Skript aus, um die Variablen auszugeben.

  • $(mySecret): Dies ist ein direkter Verweis auf die geheime Variable, der funktioniert.
  • $env:MYSECRET: Dadurch wird versucht, auf die geheime Variable als Umgebungsvariable zuzugreifen, was jedoch nicht funktioniert, da geheime Variablen Umgebungsvariablen nicht automatisch zugeordnet werden.
  • $env:GLOBAL_MYSECRET: Dadurch wird versucht, auf die geheime Variable über eine globale Variable zuzugreifen, was jedoch auch nicht funktioniert, da geheime Variablen nicht auf diese Weise zugeordnet werden können.
  • $env:GLOBAL_MY_MAPPED_ENV_VAR: Dadurch wird über eine funktionierende globale Variable auf die nicht geheime Variable zugegriffen.
  • $env:MY_MAPPED_ENV_VAR: Dadurch wird über eine aufgabenspezifische Umgebungsvariable auf die geheime Variable zugegriffen. Dies ist die Methode, die zum Zuordnen geheimer Variablen zu Umgebungsvariablen empfohlen wird.
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

Die Ausgabe beider Aufgaben aus dem vorherigen Skript sieht wie folgt aus:

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: ***

Geheime Variablen können auch außerhalb von Skripts verwendet werden. Mithilfe der variables-Definition können geheime Variablen beispielsweise Aufgaben zugeordnet werden. Im folgenden Beispiel wird gezeigt, wie Sie die geheimen Variablen $(vmsUser) und $(vmsAdminPass) in einer Azure-Dateikopieraufgabe verwenden:

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

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: AzureFileCopy@4
  inputs:
    SourcePath: 'my/path'
    azureSubscription: 'my-subscription'
    Destination: 'AzureVMs'
    storage: 'my-storage'
    resourceGroup: 'my-rg'
    vmsAdminUserName: $(VMS_USER)
    vmsAdminPassword: $(VMS_PASS)

Verweisen auf geheime Variablen in Variablengruppen

In diesem Beispiel wird gezeigt, wie Sie in Ihrer YAML-Datei auf eine Variablengruppe verweisen und wie Sie Variablen innerhalb der YAML-Datei hinzufügen. Es werden zwei Variablen aus der Variablengruppe verwendet: user und token. Die Variable token ist eine geheime Variable und der Umgebungsvariablen $env:MY_MAPPED_TOKEN zugeordnet, sodass in der YAML-Datei auf sie verwiesen werden kann.

Der folgende YAML-Code führt einen REST-Aufruf aus, um eine Liste von Releases abzurufen, und gibt das Ergebnis aus:

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

Wichtig

Bei GitHub-Repositorys werden geheime Variablen, die Ihrer Pipeline zugeordnet sind, standardmäßig nicht für Pull Request-Builds von Forks verfügbar gemacht. Weitere Informationen finden Sie unter Contributions from forks (Beiträge von Forks).

Pipelineübergreifendes Freigeben von Variablen

Verwenden Sie die Weboberfläche, um Variablen für mehrere Pipelines in Ihrem Projekt freizugeben. Verwenden Sie Variablengruppen unter Bibliothek.

Verwenden von Ausgabevariablen aus Tasks

Manche Aufgaben definieren Ausgabevariablen, die Sie in nachgelagerten Schritten, Aufträgen und Phasen nutzen können. In YAML können Sie mithilfe von Abhängigkeiten auftrags- und phasenübergreifend auf Variablen zugreifen.

Wenn Sie in nachgelagerten Aufgaben auf Matrixaufträge verweisen, müssen Sie eine andere Syntax verwenden. Weitere Informationen finden Sie unter Festlegen einer Ausgabevariablen für mehrere Aufträge. In Bereitstellungsaufträgen müssen Sie auch eine andere Syntax für Variablen verwenden. Lesen Sie: Bereitstellungsaufträge: Unterstützung für Ausgabevariablen.

Manche Aufgaben definieren Ausgabevariablen, die Sie in nachgelagerten Schritten und Aufträgen innerhalb der gleichen Phase nutzen können. In YAML können Sie mithilfe von Abhängigkeiten auftragsübergreifend auf Variablen zugreifen.

  • Verwenden Sie TASK.VARIABLE, um auf eine Variable aus einer anderen Aufgabe innerhalb des gleichen Auftrags zu verweisen.
  • Verwenden Sie dependencies.JOB.outputs['TASK.VARIABLE'], um auf eine Variable aus einer Aufgabe eines anderen Auftrags zu verweisen.

Hinweis

Standardmäßig hängt jede Phase in einer Pipeline von der Phase vor ihr in der YAML-Datei ab. Wenn Sie auf eine Phase verweisen möchten, die sich nicht unmittelbar vor der aktuellen Phase befindet, können Sie diese automatische Standardeinstellung außer Kraft setzen, indem Sie der Phase einen Abschnitt vom Typ dependsOn hinzufügen.

Hinweis

In den folgenden Beispielen wird die standardmäßige Pipelinesyntax verwendet. Bei Bereitstellungspipelines unterscheiden sich die Syntax von Variablen und bedingten Variablen. Informationen zur jeweiligen Syntax finden Sie unter Bereitstellungsaufträge.

Bei diesen Beispielen wird davon ausgegangen, dass eine Aufgabe namens MyTask vorhanden ist, die eine Ausgabevariable namens MyVar festlegt. Weitere Informationen zur Syntax finden Sie im Artikel „Ausdrücke“ unter Abhängigkeiten.

Verwenden von Ausgaben im gleichen Auftrag

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
- script: echo $(ProduceVar.MyVar) # this step uses the output variable

Verwenden von Ausgaben in einem anderen Auftrag

jobs:
- job: A
  steps:
  # assume that MyTask generates an output variable called "MyVar"
  # (you would learn that from the task's documentation)
  - task: MyTask@1
    name: ProduceVar  # because we're going to depend on it, we need to name the step
- job: B
  dependsOn: A
  variables:
    # map the output variable from A into this job
    varFromA: $[ dependencies.A.outputs['ProduceVar.MyVar'] ]
  steps:
  - script: echo $(varFromA) # this step uses the mapped-in variable

Verwenden von Ausgaben in einer anderen Phase

Um die Ausgabe einer anderen Phase zu verwenden, lautet das Format für die Referenzierung von Variablen: stageDependencies.STAGE.JOB.outputs['TASK.VARIABLE']. Auf Stufenebene, aber nicht auf Auftragsebene, können Sie diese Variablen in Bedingungen verwenden.

Ausgabevariablen sind nur in der nächsten Downstream-Stufe verfügbar. Wenn mehrere Phasen die gleiche Ausgabevariable nutzen, verwenden Sie die dependsOn-Bedingung.

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

Variablen können auch zwischen Phasen mit einer Dateieingabe übergeben werden. Dazu müssen Sie Variablen in der zweiten Phase auf Auftragsebene definieren und sie dann als env:-Eingaben übergeben.

## 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)

Die Ausgabe aus Phasen in der vorherigen Pipeline sieht wie folgt aus:

Hello inline version
true
crushed tomatoes

Auflisten von Variablen

Mithilfe des Befehls az pipelines variable list können Sie alle Variablen in Ihrer Pipeline auflisten. Informationen zu den ersten Schritten finden Sie unter Erste Schritte mit Azure DevOps CLI.

az pipelines variable list [--org]
                           [--pipeline-id]
                           [--pipeline-name]
                           [--project]

Parameter

  • org: URL der Azure DevOps-Organisation. Sie können die Standard-organization mit az devops configure -d organization=ORG_URLkonfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mit git configverwendet wird. Beispiel: --org https://dev.azure.com/MyOrganizationName/.
  • pipeline-id: Erforderlich, wenn pipeline-name nicht angegeben wird. Die ID der Pipeline.
  • pipeline-name: Erforderlich, wenn pipeline-id nicht angegeben wird. Wird allerdings ignoriert, wenn pipeline-id angegeben wird. Name der Pipeline.
  • project: Name oder ID des Projekts. Sie können das Standardprojekt mit az devops configure -d project=NAME_OR_ID konfigurieren. Erforderlich, wenn nicht als Standard konfiguriert oder mithilfe von git config übernommen.

Beispiel

Der folgende Befehl listet alle Variablen in der Pipeline mit der ID 12 auf und zeigt das Ergebnis im Tabellenformat an.

az pipelines variable list --pipeline-id 12 --output table

Name           Allow Override    Is Secret    Value
-------------  ----------------  -----------  ------------
MyVariable     False             False        platform
NextVariable   False             True         platform
Configuration  False             False        config.debug

Festlegen von Variablen in Skripts

Skripts können Variablen definieren, die in späteren Schritten in der Pipeline genutzt werden. Alle von dieser Methode festgelegten Variablen werden als Zeichenfolgen behandelt. Wenn Sie eine Variable über ein Skript festlegen möchten, verwenden Sie eine Befehlssyntax und „stdout“ für die Ausgabe.

Festlegen einer auftragsbezogenen Variablen über ein Skript

Verwenden Sie den task.setvariable-Protokollierungsbefehl, um eine Variable über ein Skript festzulegen. Dadurch werden die Umgebungsvariablen für nachfolgende Aufträge aktualisiert. Nachfolgende Aufträge haben Zugriff auf die neue Variable mit Makrosyntax und in Aufgaben als Umgebungsvariablen.

Wenn issecret den Wert „true“ hat, wird der Wert der Variablen als Geheimnis gespeichert und im Protokoll maskiert. Weitere Informationen zu geheimen Variablen finden Sie unter Protokollierungsbefehle.

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)

In nachfolgenden Schritten wird auch die Pipelinevariable zu ihrer Umgebung hinzugefügt. Sie können die Variable nicht in dem Schritt verwenden, in dem sie definiert wird.

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"

Die Ausgabe der vorherigen Pipeline:

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

Festlegen einer Ausgabevariablen für mehrere Aufträge

Wenn Sie eine Variable für zukünftige Aufträge verfügbar machen möchten, müssen Sie sie mithilfe von isOutput=true als Ausgabevariable markieren. Anschließend können Sie sie zukünftigen Aufträgen zuordnen, indem Sie die Syntax $[] verwenden und den Namen des Schritts einschließen, in dem die Variable festgelegt wurde. Ausgabevariablen für mehrere Aufträge funktionieren nur für Aufträge in der gleichen Phase.

Verwenden Sie die Syntax für Phasenabhängigkeiten, um Variablen an Aufträge in verschiedenen Phasen zu übergeben.

Hinweis

Standardmäßig hängt jede Phase in einer Pipeline von der Phase ab, die sich in der YAML-Datei unmittelbar vor ihr befindet. Daher kann jede Phase Ausgabevariablen aus der vorherigen Phase verwenden. Für den Zugriff auf weitere Phasen muss das Abhängigkeitsdiagramm geändert werden. Wenn also beispielsweise in Phase 3 eine Variable aus Phase 1 benötigt wird, müssen Sie eine explizite Abhängigkeit von Phase 1 deklarieren.

Wenn Sie eine Ausgabevariable für mehrere Aufträge erstellen, sollten Sie den Ausdruck einer Variablen zuweisen. Im folgenden YAML-Code wird $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] der Variablen $(myVarFromJobA)zugewiesen:

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

Die Ausgabe der vorherigen Pipeline:

this is the value
this is the value

Wenn Sie eine Variable von einer Phase auf eine andere festlegen, verwenden Sie 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)

Falls Sie eine Variable aus einer Matrix oder einem Slice festlegen, müssen Sie dann zum Verweisen auf die Variable, wenn Sie in einem nachgelagerten Auftrag darauf zugreifen, folgende Angaben einschließen:

  • Der Name des Auftrags.
  • Der Schritt.
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

Achten Sie darauf, den Ausgabevariablen eines Bereitstellungsauftrags den Auftragsnamen als Präfix voranzustellen. In diesem Fall lautet der Auftragsname 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

Festlegen von Variablen mithilfe von Ausdrücken

Sie können eine Variable mithilfe eines Ausdrucks festlegen. Ein solcher Fall kam in diesem Artikel bereits vor, als es darum ging, eine Variable auf die Ausgabe einer anderen Variablen aus einem vorherigen Auftrag festzulegen.

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

Sie können einen der unterstützten Ausdrücke zum Festlegen einer Variablen verwenden. Im folgenden Beispiel wird eine Variable festgelegt, die als Zähler fungiert, der bei 100 beginnt, bei jeder Ausführung um 1 erhöht wird und jeden Tag auf 100 zurückgesetzt wird.

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

Weitere Informationen zu Zählern, Abhängigkeiten und anderen Ausdrücken finden Sie unter Ausdrücke.

Konfigurieren festlegbarer Variablen für Schritte

Sie können settableVariables innerhalb eines Schritts definieren oder angeben, dass keine Variablen festgelegt werden können.

Im folgenden Beispiel kann das Skript keine Variable festlegen:

steps:
- script: echo This is a step
  target:
    settableVariables: none

Im folgenden Beispiel lässt das Skript die Variable sauce zu, aber nicht die Variable secretSauce. Auf der Pipelineausführungsseite wird eine Warnung angezeigt.

Warnung mit dem Hinweis, dass „secretSauce“ nicht festgelegt werden kann. 

steps:
  - bash: |
      echo "##vso[task.setvariable variable=Sauce;]crushed tomatoes"
      echo "##vso[task.setvariable variable=secretSauce;]crushed tomatoes with garlic"
    target:
     settableVariables:
      - sauce
    name: SetVars
  - bash: 
      echo "Sauce is $(sauce)"
      echo "secretSauce is $(secretSauce)"
    name: OutputVars

Erlauben zum Einreihungszeitpunkt

Wenn eine Variable im variables-Block einer YAML-Datei verwendet wird, handelt es sich bei ihrem Wert um einen festen Wert, der zur Warteschlangenzeit nicht außer Kraft gesetzt werden kann. Es empfiehlt sich zwar, Ihre Variablen in einer YAML-Datei zu definieren, es gibt aber auch Situationen, in denen diese Vorgehensweise nicht sinnvoll ist. Dies ist beispielsweise der Fall, wenn Sie eine geheime Variable definieren möchten und die Variable nicht in Ihrem YAML-Code offengelegt werden soll. Ein anderes mögliches Szenario wäre das manuelle Festlegen eines Variablenwerts während der Pipelineausführung.

Wenn Sie Werte zur Warteschlangenzeit definieren möchten, haben Sie zwei Möglichkeiten: Sie können eine Variable über die Benutzeroberfläche definieren und die Option Benutzern erlauben, diesen Wert beim Ausführen dieser Pipeline zu überschreiben aktivieren oder stattdessen Laufzeitparameter verwenden. Wenn Ihre Variable kein Geheimnis ist, empfiehlt es sich, Laufzeitparameter zu verwenden.

Um eine Variable zur Warteschlangenzeit festzulegen, fügen Sie in Ihrer Pipeline eine neue Variable hinzu, und aktivieren Sie die Überschreibungsoption.

Festlegen einer Variablen zur Warteschlangenzeit

Damit eine Variable zur Warteschlangenzeit festgelegt werden kann, achten Sie darauf, dass sie nicht auch im variables-Block einer Pipeline oder eines Auftrags enthalten ist. Wenn Sie eine Variable sowohl im Variablenblock einer YAML-Datei als auch über die Benutzeroberfläche definieren, hat der Wert in der YAML-Datei Priorität.

Erweiterung von Variablen

Wenn Sie in mehreren Bereichen eine Variable mit dem gleichen Namen festlegen, gilt die folgende Rangfolge (höchster Rang zuerst):

  1. In der YAML-Datei festgelegte Variable auf Auftragsebene
  2. In der YAML-Datei festgelegte Variable auf Phasenebene
  3. In der YAML-Datei festgelegte Variable auf Pipelineebene
  4. Zum Einreihungszeitpunkt festgelegte Variable
  5. Über die Benutzeroberfläche für die Pipelineeinstellungen festgelegte Variable

Im folgenden Beispiel wird die gleiche Variable a auf Pipeline- und Auftragsebene in der YAML-Datei festgelegt. Außerdem wird sie in einer Variablengruppe G, sowie als Variable auf der Benutzeroberfläche für die Pipelineeinstellungen festgelegt.

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'

Wenn Sie eine Variable mit dem gleichen Namen im gleichen Bereich festlegen, hat der letzte Wert Vorrang.

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

Hinweis

Definieren Sie eine Variable nicht im Web-Editor als zur Warteschlangenzeit festlegbar, wenn Sie die Variable in der YAML-Datei festlegen. In der YAML-Datei festgelegte Variablen können derzeit nicht zur Warteschlangenzeit geändert werden. Wenn Sie eine Variable zur Warteschlangenzeit festlegen möchten, dürfen Sie die Variable nicht in der YAML-Datei festlegen.

Variablen werden einmal erweitert, wenn die Ausführung gestartet wird, und noch einmal zu Beginn jedes Schritts. Beispiel:

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

Im vorherigen Beispiel gibt es zwei Schritte. Die Erweiterung von $(a) erfolgt einmal zu Beginn des Auftrags und jeweils zu Beginn der beiden Schritte.

Da Variablen am Anfang eines Auftrags erweitert werden, können Sie sie nicht in einer Strategie verwenden. Im folgenden Beispiel können Sie die Variable a nicht verwenden, um die Auftragsmatrix zu erweitern, da die Variable nur am Anfang jedes erweiterten Auftrags verfügbar ist.

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

Wenn es sich bei der Variablen a um eine Ausgabevariable eines vorherigen Auftrags handelt, können Sie sie in einem zukünftigen Auftrag verwenden.

- 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'] ]

Rekursive Erweiterung

Im Agent werden Variablen, auf die mithilfe der Syntax $( ) verwiesen wird, rekursiv erweitert. Zum Beispiel:

variables:
  myInner: someValue
  myOuter: $(myInner)

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