Verwenden vordefinierter Variablen

Artikel
12/12/2024

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.

Tipp

Sie können Copilot um Hilfe zu Variablen bitten. Weitere Informationen finden Sie unter Ask Copilot, eine Phase mit einer Bedingung basierend auf variablen Wertenzu generieren.

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
Klassisch

In YAML müssen Sie System.AccessToken der Pipeline explizit mithilfe einer Variablen zuordnen. Sie können dies auf Schritt- oder Vorgangsebene tun. Sie können z. B. System.AccessToken verwenden, um sich bei einer Containerregistrierung zu authentifizieren.

steps:
- task: Docker@2
  inputs:
    command: login
    containerRegistry: '<docker connection>'
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

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

System.Debug

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

Bearbeiten Sie Ihre Pipeline.
Wählen Sie Variablen aus.
Fügen Sie eine neue Variable mit dem Namen System.Debug und dem Wert true hinzu.
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.Diagnostictrue 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 `8`lautet, 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)

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.	Nein
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, die Stage 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.

Agent-Variablen (DevOps Server 2022)

Hinweis

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 Server 2022)

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. Diese Variable ist ab Azure DevOps Server 2022.1 verfügbar.	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	Siehe „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 `8`lautet, 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 Server 2022)

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.

Bereitstellungsauftragsvariablen (DevOps Server 2022)

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 Server 2022)

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.	Nein
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.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, die Stage 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 Server 2022)

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.

Agent-Variablen (DevOps Server 2020)

Hinweis

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.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 selbst gehosteten Agent verwenden, wird dieser Name von Ihnen festgelegt. 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 processor`
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).

Buildvariablen (DevOps Server 2020)

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.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 `8`lautet, 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://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. 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, nachdem der Auftrag gestartet und der Code ausgecheckt wurde). 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.	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.	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.	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.	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.	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 Server 2020)

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

Bereitstellungsauftragsvariablen (DevOps Server 2020)

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`.

Systemvariablen (DevOps Server 2020)

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	Ein zeichenfolgenbasierter Team Foundation Server-Sammlungs-URI.	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.	Nein
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.	Nein
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.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.	Ja
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` (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.TeamFoundationCollectionUri	Der URI der Team Foundation-Sammlung. 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
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

Agent-Variablen (DevOps Server 2019)

Hinweis

Variable	BESCHREIBUNG
Agent.BuildDirectory	Der lokale Pfad im Agent, in dem alle Ordner für eine bestimmte Buildpipeline erstellt werden. Beispiel: `c:\agent_work\1`
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 selbst gehosteten Agent verwenden, wird dieser Name von Ihnen festgelegt. 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 processor`
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.
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` Es ist nicht garantiert, dass Pipelineaufgaben in dieses Verzeichnis schreiben können (z. B. wenn es einem Container zugeordnet ist).

Buildvariablen (DevOps Server 2019)

Variable	BESCHREIBUNG
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. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Build.BuildId	Die ID des Datensatzes für den abgeschlossenen Build.
Build.BuildNumber	Der Name des abgeschlossenen Builds. In den Pipelineoptionen können Sie das Buildnummernformat angeben, das diesen Wert generiert. 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. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Build.BuildUri	Der URI für den Build. Beispiel: `vstfs:///Build/Build/1430` 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.
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. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
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.
Build.DefinitionVersion	Die Version der Buildpipeline.
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.
Build.QueuedById	Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“.
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. Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Branchrichtlinien.
Build.Repository.Clean	Der Wert, den Sie für Clean in den Einstellungen des Quellrepositorys ausgewählt haben. 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.
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. 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. Diese Variable ist synonym mit Build.SourcesDirectory.
Build.Repository.Name	Der Name des Repositorys. 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.
Build.Repository.Provider	Der Typ des von Ihnen ausgewählten 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. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
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 `8`lautet, könnte der Arbeitsbereichsname `ws_12_8` lauten: 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.
Build.Repository.Uri	Die URL für das Repository. Beispiel: Git: https://dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ 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.
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.
Build.RequestedForEmail	Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“.
Build.RequestedForId	Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“.
Build.SourceBranch	Der Branch, 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` 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.
Build.SourceBranchName	Der Name des Branchs, 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.
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. 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. Diese Variable ist synonym mit Build.Repository.LocalPath.
Build.SourceVersion	Die neueste Versionskontrolländerung, die in diesem Build enthalten ist. Git: die Commit-ID. TFVC: das Changeset. 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.
Build.SourceVersionMessage	Der Kommentar des Commits oder des Changesets. Wir kürzen die Meldung auf die erste Zeile bzw. 200 Zeichen, je nachdem, was kürzer ist. 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. 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.
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. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Build.Repository.Git.SubmoduleCheckout	Der Wert, den Sie auf der Registerkarte Repository für Submodule auschecken ausgewählt haben. 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.
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.
Build.TriggeredBy.BuildId	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die BuildID des auslösenden Builds festgelegt. 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.
Build.TriggeredBy.DefinitionId	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt. 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.
Build.TriggeredBy.DefinitionName	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. 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.
Build.TriggeredBy.BuildNumber	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die Nummer des auslösenden Builds festgelegt. 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.
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. 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.
Common.TestResultsDirectory	Der lokale Pfad im Agent, in dem die Testergebnisse erstellt werden. Beispiel: `c:\agent_work\1\TestResults` 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.

Systemvariablen (DevOps Server 2019)

PowerShell-Beispielskript: Zugriff auf REST-API

Variable	BESCHREIBUNG
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. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
System.CollectionId	Die GUID der TFS-Sammlung oder Azure DevOps-Organisation.
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.
System.DefinitionId	Die ID der Buildpipeline.
System.HostType	Auf `build` festgelegt, wenn die Pipeline ein Build ist. Bei einem Release lauten die Werte `deployment` für einen Bereitstellungsgruppenauftrag und `release` für einen Agent-Auftrag.
System.PullRequest.IsFork	Wenn der Pull Request aus einem Fork des Repositorys stammt, wird diese Variable auf `True` festgelegt. Andernfalls wird sie auf `False` festgelegt.
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.)
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.
System.PullRequest.SourceBranch	Der Branch, der in einem Pull Request überprüft wird. Beispiel: `refs/heads/users/raisa/new-feature` (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt.)
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.)
System.PullRequest.SourceRepositoryURI	Die URL zu dem Repository, das den Pull Request enthält. Beispiel: `https://dev.azure.com/ouraccount/_git/OurProject` (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Azure Repos-Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt. Sie wird nicht für GitHub-PRs initialisiert.)
System.PullRequest.TargetBranch	Der Branch, der Ziel eines Pull Requests ist. Beispiel: `refs/heads/main` Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt.
System.TeamFoundationCollectionUri	Der URI der Team Foundation-Sammlung. Beispiel: `https://dev.azure.com/fabrikamfiber/` 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.
System.TeamProject	Der Name des Projekts, das diesen Build enthält.
System.TeamProjectId	Die ID des Projekts, zu dem dieser Build gehört.
TF_BUILD	Auf `True` festgelegt, wenn das Skript von einer Buildaufgabe ausgeführt wird. 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.

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

Bitten Sie Copilot, eine Phase mit einer Bedingung basierend auf variablen Werten zu generieren

Verwenden Sie Copilot-, um eine Phase mit einer Bedingung zu generieren, die durch den Wert einer Variablen bestimmt wird.

In dieser Beispielaufforderung wird eine Phase definiert, die ausgeführt wird, wenn Agent.JobStatus angibt, dass die vorherige Phase erfolgreich ausgeführt wurde:

Erstellen Sie eine neue Azure DevOps-Phase, die nur ausgeführt wird, wenn Agent.JobStatusSucceeded oder SucceededWithIssuesist.

Sie können die Eingabeaufforderung so anpassen, dass Werte verwendet werden, die Ihren Anforderungen entsprechen. Sie können z. B. Hilfe beim Erstellen einer Phase anfordern, die nur ausgeführt wird, wenn eine Pipeline fehlschlägt.

Hinweis

GitHub Copilot wird von KI unterstützt, sodass Überraschungen und Fehler möglich sind. Stellen Sie sicher, dass Sie generierten Code oder Vorschläge überprüfen. Weitere Informationen zur allgemeinen Verwendung von GitHub Copilot, Produktwirkungen, menschlicher Aufsicht und Datenschutz finden Sie unter GitHub Copilot FAQs.

Freigeben über

Verwenden vordefinierter Variablen

Build.Clean

System.AccessToken

System.Debug

Agent-Variablen (DevOps Services)

Buildvariablen (DevOps Services)

Pipelinevariablen (DevOps Services)

Variablen für Bereitstellungsaufträge (DevOps Services)

Systemvariablen (DevOps Services)

Prüfvariablen (DevOps Services)

Agent-Variablen (DevOps Server 2022)

Buildvariablen (DevOps Server 2022)

Pipelinevariablen (DevOps Server 2022)

Bereitstellungsauftragsvariablen (DevOps Server 2022)

Systemvariablen (DevOps Server 2022)

Prüfvariablen (DevOps Server 2022)

Agent-Variablen (DevOps Server 2020)

Buildvariablen (DevOps Server 2020)

Pipelinevariablen (DevOps Server 2020)

Bereitstellungsauftragsvariablen (DevOps Server 2020)

Systemvariablen (DevOps Server 2020)

Agent-Variablen (DevOps Server 2019)

Buildvariablen (DevOps Server 2019)

Systemvariablen (DevOps Server 2019)

Wie werden die Identitätsvariablen festgelegt?

Bitten Sie Copilot, eine Phase mit einer Bedingung basierend auf variablen Werten zu generieren

Feedback

Zusätzliche Ressourcen