Verwenden vordefinierter Variablen

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

Variablen sind eine praktische Möglichkeit, wichtige Daten in verschiedene Teile Ihrer Pipeline einzufügen. Dies ist eine Liste vordefinierter Variablen, die für Sie zur Verwendung zur Verfügung stehen. Es gibt möglicherweise weitere vordefinierte Variablen, aber diese sind hauptsächlich für die interne Verwendung vorgesehen.

Diese Variablen werden automatisch vom System festgelegt und sind schreibgeschützt. (Eine Ausnahme bilden „Build.Clean“ und „System.Debug“.)

In YAML-Pipelines können Sie auf vordefinierte Variablen als Umgebungsvariablen verweisen. Beispielsweise wird die Variable Build.ArtifactStagingDirectory zur Variablen BUILD_ARTIFACTSTAGINGDIRECTORY.

Bei klassischen Pipelines können Sie Releasevariablen in Ihren Bereitstellungsaufgaben verwenden, um allgemeine Informationen weiterzugeben (z. B. Umgebungsname, Ressourcengruppe usw.).

Erfahren Sie mehr über das Arbeiten mit Variablen.

Build.Clean

Dies ist eine als veraltet markierte Variable, die die Art und Weise ändert, in der der Build-Agent die Quelle bereinigt. Informationen zum Bereinigen von Quellen finden Sie unter Bereinigen des lokalen Repositorys für den Agent.

System.AccessToken

System.AccessToken ist eine spezielle Variable, die das vom ausgeführten Build verwendete Sicherheitstoken enthält.

YAML

In YAML müssen Sie System.AccessToken der Pipeline explizit mithilfe einer Variablen zuordnen. Sie können dies auf Schritt- oder Aufgabenebene tun:

steps:
  - script: |
      echo "Using System.AccessToken to authenticate"
      git clone https://$(System.AccessToken)@dev.azure.com/yourorganization/yourproject/_git/yourrepository
    displayName: 'Clone repository using System.AccessToken'
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Sie können den Standardbereich für System.AccessToken mit dem Autorisierungsbereich des Buildauftrags konfigurieren.

Klassisch

Sie können Skripts und Aufgaben den Zugriff auf „System.AccessToken“ auf Auftragsebene ermöglichen.

1. Navigieren zum Auftrag

2. Aktivieren Sie unter Zusätzliche Optionen das Kontrollkästchen Skripts den Zugriff auf das OAuth-Token erlauben.

Wenn Sie dieses Kontrollkästchen aktivieren, bleiben auch die Anmeldeinformationen in Git festgelegt, sodass Sie Push- und Pullvorgänge in Ihren Skripts ausführen können.

System.Debug

Um ausführlichere Protokolle zum Debuggen von Pipelineproblemen zu erhalten, definieren Sie System.Debug, und legen Sie den Wert auf true fest.

1. Bearbeiten Sie Ihre Pipeline.

2. Wählen Sie Variablen aus.

3. Fügen Sie eine neue Variable mit dem Namen System.Debug und dem Wert true hinzu.

   

4. Speichern Sie die neue Variable.

Wenn Sie System.Debug auf true festlegen, werden ausführliche Protokolle für alle Ausführungen konfiguriert. Sie können auch mit dem Kontrollkästchen Systemdiagnose aktivieren ausführliche Protokolle für eine einzelne Ausführung konfigurieren.

Sie können System.Debug auch als Variable in einer Pipeline oder Vorlage auf true festlegen.

variables:
  system.debug: 'true'

Wenn System.Debug auf true festgelegt ist, wird eine zusätzliche Variable mit dem Namen „Agent.Diagnostic“ auf true festgelegt. Wenn Agent.Diagnostic true ist, sammelt der Agent weitere Protokolle, die für die Problembehandlung von Netzwerkproblemen für selbst gehostete Agents verwendet werden können. Weitere Informationen finden Sie unter Netzwerkdiagnose für selbstgehostete Agents.

Hinweis

Die Agent.Diagnostic-Variable ist mit Agent v2.200.0 und höher verfügbar.

Weitere Informationen finden Sie unter Überprüfen von Protokollen zur Diagnose von Pipelineproblemen.

Agent-Variablen (DevOps Services)

Hinweis

Sie können Agent-Variablen als Umgebungsvariablen in Ihren Skripts und als Parameter in Ihren Buildaufgaben verwenden. Sie können sie nicht verwenden, um die Buildnummer anzupassen oder eine Bezeichnung oder ein Tag für die Versionskontrolle anzuwenden.

Variable	BESCHREIBUNG
Agent.BuildDirectory	Der lokale Pfad im Agent, in dem alle Ordner für eine bestimmte Buildpipeline erstellt werden. Diese Variable hat denselben Wert wie Pipeline.Workspace. Beispiel: /home/vsts/work/1
Agent.ContainerMapping	Eine Zuordnung von Containerressourcennamen in YAML zu ihren Docker-IDs zur Laufzeit. Die folgende Tabelle zeigt ein Beispiel.
Agent.HomeDirectory	Das Verzeichnis, in dem der Agent installiert ist. Es enthält die Agent-Software. Beispiel: c:\agent.
Agent.Id	Die ID der Momentaufnahme.
Agent.JobName	Der Name des derzeit ausgeführten Auftrags. Dieser lautet in der Regel „Job“ oder „__default“, in Multikonfigurationsszenarien handelt es sich jedoch um die Konfiguration.
Agent.JobStatus	Der Status des Builds. Canceled Failed Succeeded SucceededWithIssues (teilweise erfolgreich) Skipped (letzter Auftrag) Auf die Umgebungsvariable sollte als AGENT_JOBSTATUS verwiesen werden. Der ältere agent.jobstatus ist aus Gründen der Abwärtskompatibilität verfügbar.
Agent.MachineName	Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name	Der Name des Agents, der im Pool registriert ist. Wenn Sie einen selbstgehosteten Agent verwenden, wird dieser Name von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.
Agent.OS	Das Betriebssystem des Agent-Hosts. Gültige Werte sind: Windows_NT Darwin Linux Bei Ausführung in einem Container können Agent-Host und Container unterschiedliche Betriebssysteme ausführen.
Agent.OSArchitecture	Die Betriebssystem-Prozessorarchitektur des Agent-Hosts. Gültige Werte sind: X86 X64 ARM
Agent.TempDirectory	Ein temporärer Ordner, der nach jedem Pipelineauftrag bereinigt wird. Dieses Verzeichnis wird von Aufgaben wie der .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu speichern, bevor sie veröffentlicht werden. Beispiel: /home/vsts/work/_temp für Ubuntu.
Agent.ToolsDirectory	Das Verzeichnis, das von Aufgaben wie dem Node-Tool-Installer und Use Python Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis zu PATH hinzu, damit nachfolgende Buildschritte sie verwenden können. Erfahren Sie mehr über das Verwalten dieses Verzeichnisses in einem selbst gehosteten Agent.
Agent.WorkFolder	Das Arbeitsverzeichnis für diesen Agent. Beispiel: c:\agent_work Hinweis: Es ist nicht garantiert, dass Pipelineaufgaben in dieses Verzeichnis schreiben können (z. B. wenn es einem Container zugeordnet ist).

Beispiel für Agent.ContainerMapping:

{
  "one_container": {
    "id": "bdbb357d73a0bd3550a1a5b778b62a4c88ed2051c7802a0659f1ff6e76910190"
  },
  "another_container": {
    "id": "82652975109ec494876a8ccbb875459c945982952e0a72ad74c91216707162bb"
  }
}

Buildvariablen (DevOps Services)

Wenn Sie eine Variable in einer Vorlage verwenden, die in Vorlagen nicht als verfügbar gekennzeichnet ist, wird die Variable nicht dargestellt. Die Variable wird nicht dargestellt, da auf den Wert im Bereich der Vorlage nicht zugegriffen werden kann.

Variable	BESCHREIBUNG	In Vorlagen verfügbar?
Build.ArtifactStagingDirectory	Der lokale Pfad im Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden. Beispiel: c:\agent_work\1\a Eine typische Verwendungsweise dieses Ordners besteht darin, Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte veröffentlichen zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind untereinander austauschbar. Dieses Verzeichnis wird vor jedem neuen Build bereinigt, Sie müssen den Bereinigungsvorgang also nicht selbst ausführen. Weitere Informationen finden Sie unter Artefakte in Azure Pipelines. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.BuildId	Die ID des Datensatzes für den abgeschlossenen Build.	Nein
Build.BuildNumber	Der Name des abgeschlossenen Builds, auch als Ausführungsnummer bezeichnet. Sie können angeben, was in diesem Wert enthalten ist. Eine typische Verwendung dieser Variablen besteht darin, sie zu einem Teil des Bezeichnungsformats zu machen, das Sie auf der Registerkarte Repository angeben. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen tritt beim Bezeichnungsformat ein Fehler auf. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.BuildUri	Der URI für den Build. Beispiel: vstfs:///Build/Build/1430. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.BinariesDirectory	Der lokale Pfad im Agent, den Sie als Ausgabeordner für kompilierte Binärdateien verwenden können. Standardmäßig sind neue Buildpipelines nicht so eingerichtet, dass dieses Verzeichnis bereinigt wird. Sie können Ihren Build auf der Registerkarte Repository so definieren, dass eine Bereinigung durchgeführt wird. Beispiel: c:\agent_work\1\b. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.ContainerId	Die ID des Containers für Ihr Artefakt. Wenn Sie ein Artefakt in Ihre Pipeline hochladen, wird es einem Container hinzugefügt, der speziell für dieses bestimmte Artefakt gilt.	Nein
Build.CronSchedule.DisplayName	Der displayName des Cron-Zeitplans, der die Pipelineausführung ausgelöst hat. Diese Variable wird nur festgelegt, wenn die Pipelineausführung durch einen geplanten YAML-Trigger ausgelöst wird. Weitere Informationen finden Sie unter schedules.cron definition – Build.CronSchedule.DisplayName-Variable	Ja
Build.DefinitionName	Der Name der Buildpipeline. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen tritt beim Bezeichnungsformat ein Fehler auf.	Ja
Build.DefinitionVersion	Die Version der Buildpipeline.	Ja
Build.QueuedBy	Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen tritt beim Bezeichnungsformat ein Fehler auf.	Ja
Build.QueuedById	Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“.	Ja
Build.Reason	Das Ereignis, das die Ausführung des Builds verursacht hat. Manual: Der Build wurde benutzerseitig manuell in die Warteschlange eingereiht. IndividualCI: Continuous Integration (CI), ausgelöst durch einen Git-Push- oder TFVC-Check-In-Vorgang. BatchedCI: Continuous Integration (CI), ausgelöst durch einen Git-Push- oder TFVC-Check-In-Vorgang, mit Auswahl von Batchänderungen. Schedule: Geplanter Trigger. ValidateShelveset: Der Build eines bestimmten TFVC-Shelvesets wurde benutzerseitig manuell in die Warteschlange eingereiht. CheckInShelveset: Gated-Check-In-Trigger. PullRequest: Der Build wurde durch eine Git-Branch-Richtlinie ausgelöst, die einen Build erfordert. BuildCompletion: Der Build wurde durch einen anderen Build ausgelöst. ResourceTrigger: Der Build wurde durch einen Ressourcentrigger oder durch einen anderen Build ausgelöst. Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Branchrichtlinien.	Ja
Build.Repository.Clean	Der Wert, den Sie für Clean in den Einstellungen des Quellrepositorys ausgewählt haben. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.Repository.LocalPath	Der lokale Pfad im Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Auf der Registerkarte Repository können Sie ändern, auf welche Weise Dateien heruntergeladen werden. Wichtiger Hinweis: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code. Wenn Sie mehrere Repositorys auschecken, lautet das Verhalten wie folgt (und unterscheidet sich möglicherweise vom Wert der Build.SourcesDirectory-Variablen): Wenn im Check-Out-Schritt für das (primäre) self-Repository (primär) kein benutzerdefinierter Check-Out-Pfad definiert ist oder der Check-Out-Pfad der Multi-Check-Out-Standardpfad $(Pipeline.Workspace)/s/&<RepoName> für das self-Repository ist, wird der Wert dieser Variablen auf den Standardwert zurückgesetzt: $(Pipeline.Workspace)/s. Wenn im Check-Out-Schritt für das (primäre) self-Repository ein benutzerdefinierter Check-Out-Pfad definiert ist (und nicht der Multi-Check-Out-Standardpfad ist), enthält diese Variable den genauen Pfad zum self-Repository. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.Repository.ID	Der eindeutige Bezeichner des Repositorys. Dieser ändert sich nicht, auch wenn der Name des Repositorys sich ändert. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.Repository.Name	Der Name des auslösenden Repositorys. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.Repository.Provider	Der Typ des auslösenden Repositorys. TfsGit: TFS-Git-Repository TfsVersionControl: Team Foundation-Versionskontrolle Git: Git-Repository, das auf einem externen Server gehostet wird GitHub Svn: Subversion Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.Repository.Tfvc.Workspace	Definiert, ob Ihr Repository der Team Foundation-Versionskontrolle unterliegt. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird. Wenn das Agent.BuildDirectory beispielsweise c:\agent_work\12 und die Agent.Id 8lautet, könnte der Arbeitsbereichsname ws_12_8 lauten. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.Repository.Uri	Die URL für das auslösende Repository. Beispiel: Git: https://fabrikamfiber@dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.RequestedFor	Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen tritt beim Bezeichnungsformat ein Fehler auf.	Ja
Build.RequestedForEmail	Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“.	Ja
Build.RequestedForId	Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“.	Ja
Build.SourceBranch	Der Branch des auslösenden Repositorys, für den der Build in die Warteschlange eingereiht wurde. Einige Beispiele: Branch des Git-Repositorys: refs/heads/main Pull Request für Git-Repository: refs/pull/1/merge Branch des TFVC-Repositorys: $/teamproject/main Gated-Check-In des TFVC-Repositorys: Gated_2016-06-06_05.20.51.4369;username@live.com Shelvesetbuild des TFVC-Repositorys: myshelveset;username@live.com Auslösung Ihrer Pipeline durch ein Tag: refs/tags/your-tag-name Wenn Sie diese Variable in Ihrem Buildnummernformat verwenden, werden die Schrägstriche (/) durch Unterstriche (_) ersetzt. Hinweis: Wenn Sie in TFVC einen Gated-Check-In-Build ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht in Ihrem Buildnummernformat verwenden.	Ja
Build.SourceBranchName	Der Name des Branchs im auslösenden Repository, für den der Build in die Warteschlange eingereiht wurde. Branch, Pull Request oder Tag des Git-Repositorys: das letzte Pfadsegment im Verweis. In refs/heads/main lautet dieser Wert beispielsweise main. In refs/heads/feature/tools lautet der Wert tools. In refs/tags/your-tag-name lautet der Wert your-tag-name. Branch des TFVC-Repositorys: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In $/teamproject/main lautet dieser Wert beispielsweise main. Der Gated-Check-In-Build oder Shelvesetbuild des TFVC-Repositorys ist der Name des Shelvesets. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com. Hinweis: Wenn Sie in TFVC einen Gated-Check-In-Build ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht in Ihrem Buildnummernformat verwenden.	Ja
Build.SourcesDirectory	Der lokale Pfad im Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Wichtiger Hinweis: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code. Wenn Sie mehrere Repositorys auschecken, wird er auf den Standardwert zurückgesetzt, der $(Pipeline.Workspace)/s lautet, auch wenn das (primäre) Self-Repository in einem benutzerdefinierten Pfad ausgecheckt ist, der sich vom Multi-Check-Out-Standardpfad $(Pipeline.Workspace)/s/<RepoName> unterscheidet (in diesem Fall unterscheidet sich das Verhalten der Variablen von dem der Build.Repository.LocalPath-Variablen). Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.SourceVersion	Die neueste Versionskontrolländerung des auslösenden Repositorys, die in diesem Build enthalten ist. Git: die Commit-ID. TFVC: das Changeset. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Ja
Build.SourceVersionMessage	Der Kommentar des Commits oder des Changesets für das auslösende Repository. Wir kürzen die Meldung auf die erste Zeile bzw. 200 Zeichen, je nachdem, was kürzer ist. Die Build.SourceVersionMessage entspricht der Meldung beim Build.SourceVersion-Commit. Der Build.SourceVersion-Commit für einen PR-Build ist der Mergecommit (nicht der Commit im Quellbranch). Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag. Außerdem ist diese Variable nur auf Schrittebene und nicht auf den Auftrags- oder Phasenebenen verfügbar (d. h. die Nachricht wird erst extrahiert, wenn der Auftrag gestartet wird und der Code ausgecheckt ist). Hinweis: Diese Variable ist in TFS 2015.4 verfügbar. Hinweis: Die Build.SourceVersionMessage-Variable funktioniert nicht mit klassischen Buildpipelines in Bitbucket-Repositorys, wenn Batchänderungen während der Durchführung eines Builds aktiviert ist.	Nein
Build.StagingDirectory	Der lokale Pfad im Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden. Beispiel: c:\agent_work\1\a Eine typische Verwendungsweise dieses Ordners besteht darin, Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte veröffentlichen zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind untereinander austauschbar. Dieses Verzeichnis wird vor jedem neuen Build bereinigt, Sie müssen den Bereinigungsvorgang also nicht selbst ausführen. Weitere Informationen finden Sie unter Artefakte in Azure Pipelines. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.Repository.Git.SubmoduleCheckout	Der Wert, den Sie auf der Registerkarte Repository für Submodule auschecken ausgewählt haben. Wenn mehrere Repositorys ausgecheckt sind, verfolgt dieser Wert die Einstellung des auslösenden Repositorys nach. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein
Build.SourceTfvcShelveset	Definiert, ob Ihr Repository der Team Foundation-Versionskontrolle unterliegt. Wenn Sie einen Gated-Build oder einen Shelvesetbuild ausführen, ist dies auf den Namen des Shelvesets festgelegt, das Sie erstellen. Hinweis: Diese Variable liefert einen Wert, der für die Buildverwendung in einem Buildnummernformat ungültig ist.	Nein
Build.TriggeredBy.BuildId	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die BuildID des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag. Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.DefinitionId	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag. Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.DefinitionName	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag. Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.BuildNumber	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die Nummer des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag. Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.ProjectID	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die ID des Projekts festgelegt, das den auslösenden Build enthält. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag. Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Common.TestResultsDirectory	Der lokale Pfad im Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein

Pipelinevariablen (DevOps Services)

Variable	BESCHREIBUNG
Pipeline.Workspace	Arbeitsbereichsverzeichnis für eine bestimmte Pipeline. Diese Variable hat denselben Wert wie Agent.BuildDirectory. Beispiel: /home/vsts/work/1.

Tipp

Wenn Sie klassische Releasepipelines verwenden, können Sie klassische Release- und Artefaktvariablen verwenden, um Daten in der gesamten Pipeline zu speichern und darauf zuzugreifen.

Variablen für Bereitstellungsaufträge (DevOps Services)

Diese Variablen sind auf einen bestimmten Bereitstellungsauftrag festgelegt und werden erst zur Ausführungszeit des Auftrags aufgelöst.

Variable	BESCHREIBUNG
Environment.Name	Der Name der Umgebung, die im Bereitstellungsauftrag als Ziel der Ausführung der Bereitstellungsschritte und der Aufzeichnung des Bereitstellungsverlaufs verwendet wird. Beispiel: smarthotel-dev.
Environment.Id	Die ID der Umgebung, die im Bereitstellungsauftrag als Ziel verwendet wird. Beispiel: 10.
Environment.ResourceName	Der Name der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag als Ziel der Ausführung der Bereitstellungsschritte und der Aufzeichnung des Bereitstellungsverlaufs verwendet wird. Ein Beispiel ist bookings – ein Kubernetes-Namespace, der der Umgebung smarthotel-dev als Ressource hinzugefügt wurde.
Environment.ResourceId	Die ID der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag als Ziel der Ausführung der Bereitstellungsschritte verwendet wird. Beispiel: 4.
Strategy.Name	Der Name der Bereitstellungsstrategie: canary, runOnce oder rolling.
Strategy.CycleName	Der Name des aktuellen Zyklus in einer Bereitstellung. Die Optionen sind PreIteration, Iteration oder PostIteration.

Systemvariablen (DevOps Services)

Wenn Sie eine Variable in einer Vorlage verwenden, die in Vorlagen nicht als verfügbar gekennzeichnet ist, wird die Variable nicht dargestellt. Die Variable wird nicht dargestellt, da auf den Wert im Bereich der Vorlage nicht zugegriffen werden kann.

Variable	BESCHREIBUNG	In Vorlagen verfügbar?
System.AccessToken	Verwenden des OAuth-Tokens für den Zugriff auf die REST-API. Verwenden von System.AccessToken aus YAML-Skripts. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Ja
System.CollectionId	Die GUID der TFS-Sammlung oder Azure DevOps-Organisation.	Ja
System.CollectionUri	Der URI der TFS-Sammlung oder Azure DevOps-Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/.	Ja
System.DefaultWorkingDirectory	Der lokale Pfad im Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Auf der Registerkarte Repository können Sie ändern, auf welche Weise Dateien heruntergeladen werden. Diese Variable ist Agent-bezogen. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Ja
System.DefinitionId	Die ID der Buildpipeline.	Ja
System.HostType	Auf build festgelegt, wenn die Pipeline ein Build ist. Bei einem Release lauten die Werte deployment für einen Bereitstellungsgruppenauftrag, gates während der Auswertung von Gates und release für andere Aufträge (mit oder ohne Agent).	Ja
System.JobAttempt	Auf 1 festgelegt, wenn die Ausführung des Auftrags zum ersten Mal versucht wird, erhöht sich bei jedem neuen Versuch, den Auftrag auszuführen.	Nein
System.JobDisplayName	Der für Menschen lesbare Name eines Auftrags.	Nein
System.JobId	Ein eindeutiger Bezeichner für einen einzelnen Versuch eines einzelnen Auftrags. Der Wert ist für die aktuelle Pipeline eindeutig.	Nein
System.JobName	Der Name des Auftrags, wird in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet.	No
System.OidcRequestUri	Generieren Sie ein ID-Token (idToken) für die Authentifizierung mit Entra ID mithilfe von OpenID Connect (OIDC). Weitere Informationen	Ja
System.PhaseAttempt	Auf 1 festgelegt, wenn die Phase zum ersten Mal versucht wird, erhöht sich bei jedem neuen Versuch, den Auftrag auszuführen. Hinweis: „Phase“ ist ein weitgehend redundantes Konzept, das die Entwurfszeit für einen Auftrag darstellt (während ein Auftrag die Laufzeitversion einer Phase war). Wir haben das Konzept der Phasen größtenteils aus Azure Pipelines entfernt. Matrix- und Multikonfigurationsaufträge sind die einzige Stelle, an der eine „Phase“ sich noch von einem „Auftrag“ unterscheidet. Eine Phase kann mehrere Aufträge instanziieren, die sich nur in ihren Eingaben unterscheiden.	Nein
System.PhaseDisplayName	Der für Menschen lesbare Name einer Phase.	Nein
System.PhaseName	Ein zeichenfolgenbasierter Bezeichner für einen Auftrag, wird in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet.	Nein
System.PlanId	Ein zeichenfolgenbasierter Bezeichner für eine einzelne Pipelineausführung.	Nein
System.PullRequest.IsFork	Wenn der Pull Request aus einem Fork des Repositorys stammt, wird diese Variable auf True festgelegt. Andernfalls ist sie auf False festgelegt.	Ja
System.PullRequest.PullRequestId	Die ID des Pull Requests, der diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt).	Nein
System.PullRequest.PullRequestNumber	Die Nummer des Pull Requests, der diesen Build verursacht hat. Diese Variable wird für Pull Requests von GitHub aufgefüllt, die eine andere Pull Request-ID und Pull Request-Nummer aufweisen. Diese Variable ist nur dann in einer YAML-Pipeline verfügbar, wenn sich eine Branchrichtlinie auf den PR auswirkt.	Nein
System.PullRequest.targetBranchName	Der Name des Zielbranchs für einen Pull Request. Diese Variable kann in einer Pipeline verwendet werden, um Aufgaben oder Schritte basierend auf dem Zielbranch des Pull Requests bedingt auszuführen. Sie können z. B. je nach Branch, in den die Änderungen gemergt werden, eine andere Reihe von Tests oder Codeanalysetools auslösen.	Nein
System.PullRequest.SourceBranch	Der Branch, der in einem Pull Request überprüft wird. Beispiel: refs/heads/users/raisa/new-feature für Azure Repos. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt). Diese Variable ist nur dann in einer YAML-Pipeline verfügbar, wenn sich eine Branchrichtlinie auf den PR auswirkt.	Nein
System.PullRequest.SourceCommitId	Der Commit, der in einem Pull Request überprüft wird. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt). Diese Variable ist nur dann in einer YAML-Pipeline verfügbar, wenn sich eine Branchrichtlinie auf den PR auswirkt.
System.PullRequest.SourceRepositoryURI	Die URL zu dem Repository, das den Pull Request enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject.	Nein
System.PullRequest.TargetBranch	Der Branch, der Ziel eines Pull Requests ist. Beispiel: refs/heads/main, wenn sich Ihr Repository in Azure Repos befindet, und main, wenn sich Ihr Repository in GitHub befindet. Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt. Diese Variable ist nur dann in einer YAML-Pipeline verfügbar, wenn sich eine Branchrichtlinie auf den PR auswirkt.	Nein
System.StageAttempt	Auf 1 festgelegt, wenn die Stage zum ersten Mal versucht wird, erhöht sich bei jedem neuen Versuch, den Auftrag auszuführen.	Nein
System.StageDisplayName	Der für Menschen lesbare Name einer Stage.	Nein
System.StageName	Ein zeichenfolgenbasierter Bezeichner für eine Stage, wird in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet.	Nein
System.TeamFoundationCollectionUri	Der URI der TFS-Sammlung oder Azure DevOps-Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Ja
System.TeamProject	Der Name des Projekts, das diesen Build enthält.	Ja
System.TeamProjectId	Die ID des Projekts, zu dem dieser Build gehört.	Ja
System.TimelineId	Ein zeichenfolgenbasierter Bezeichner für die Ausführungsdetails und Protokolle einer einzelnen Pipelineausführung.	Nein
TF_BUILD	Auf True festgelegt, wenn das Skript von einer Buildaufgabe ausgeführt wird. Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.	Nein

Prüfvariablen (DevOps Services)

Variable	BESCHREIBUNG
Checks.StageAttempt	Auf 1 festgelegt, wenn die Stage zum ersten Mal versucht wird, erhöht sich bei jedem neuen Versuch, die Stage auszuführen. Diese Variable kann nur im Rahmen einer Genehmigung oder Überprüfung für eine Umgebung verwendet werden. Sie können $(Checks.StageAttempt) z. B. beim Aufruf einer REST-API-Überprüfung verwenden.

Wie werden die Identitätsvariablen festgelegt?

Der Wert hängt davon ab, was den Build verursacht hat, und ist spezifisch für Azure Repos-Repositorys.

Beim Auslösen des Builds	Werte für Build.QueuedBy und Build.QueuedById basieren auf	Werte für Build.RequestedFor und Build.RequestedForId basieren auf
In Git oder durch die Trigger für Continuous Integration (CI)	Die Systemidentität, z. B. [DefaultCollection]\Project Collection Service Accounts	Die Person, die die Änderungen gepusht oder eingecheckt hat.
In Git oder durch einen Branchrichtlinienbuild.	Die Systemidentität, z. B. [DefaultCollection]\Project Collection Service Accounts	Die Person, die die Änderungen eingecheckt hat.
In TFVC durch einen Gated-Check-In-Trigger	Die Person, die die Änderungen eingecheckt hat.	Die Person, die die Änderungen eingecheckt hat.
In Git oder TFVC durch die geplanten Trigger	Die Systemidentität, z. B. [DefaultCollection]\Project Collection Service Accounts	Die Systemidentität, z. B. [DefaultCollection]\Project Collection Service Accounts
Durch Klicken auf die Schaltfläche Build in Warteschlange einreihen	Sie	Sie