Verwenden vordefinierter Variablen

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

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

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

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

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

Erfahren Sie mehr über das Arbeiten mit Variablen.

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

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.

Klassisch

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

1. Navigieren zum Auftrag

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

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

System.Debug

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

1. Bearbeiten Sie Ihre Pipeline.

2. Wählen Sie Variablen aus.

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

   

4. Speichern Sie die neue Variable.

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

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

variables:
  system.debug: 'true'

Wenn System.Debug auf true festgelegt ist, wird eine zusätzliche Variable mit dem Namen „Agent.Diagnostic“ auf true festgelegt. Wenn Agent.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 Versionssteuerungsbezeichnung oder ein Tag 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 Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur.
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. Diese Variable enthält die Agentsoftware. Beispiel: c:\agent Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur.
Agent.Id	Die ID der Momentaufnahme.
Agent.JobName	Der Name des derzeit ausgeführten Auftrags. Dieser Name ist in der Regel Job; oder __default, aber in Szenarien mit mehreren Konfigurationen ist dies 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, geben Sie den Namen an. Weitere Informationen finden Sie unter Agents.
Agent.OS	Das Betriebssystem des Agent-Hosts. Gültige Werte sind: Windows_NT Darwin Linux Wenn Sie in einem Container ausgeführt werden, kann der Agenthost und der Container verschiedene 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). Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur.

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 gerendert. Die Variable wird nicht gerendert, 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. Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	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-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein
Build.BuildUri	Der URI für den Build. Beispiel: vstfs:///Build/Build/1430 Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein
Build.BinariesDirectory	Der lokale Pfad im Agent, den Sie als Ausgabeordner für kompilierte Binärdateien verwenden können. Bei selbst gehosteten Agents sind neue Buildpipelinen nicht so eingerichtet, dass dieses Verzeichnis standardmäßig 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 Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	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 ein geplanter YAML-Trigger die Pipelineausführung auslöst. 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	Siehe 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: kontinuierlichen Integration (Continuous Integration, CI) ausgelöst von einem Git-Push oder einem TFVC-Check-In (Team Foundation Version Control). 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: Eine Git Branch-Richtlinie, die einen Build erfordert, löst den Build aus. BuildCompletion: Ein anderer Build löst den Build aus. ResourceTrigger: Ein Ressourcentrigger oder einem anderen Buildtrigger build. 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 Quell-Repositoryeinstellungenausgewählt haben. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein
Build.Repository.LocalPath	Der lokale Pfad im Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Bei selbst gehosteten Agents aktualisieren neue Buildpipelinen standardmäßig 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 der Auscheckschritt für das Selbst-Repository (primäres) Repository einen benutzerdefinierten Auscheckpfad definiert hat, der nicht der Standardpfad mit mehreren Auscheckvorgängen ist, enthält diese Variable den genauen Pfad zum Selbst-Repository. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein
Build.Repository.ID	Der eindeutige Bezeichner des Repositorys. Dieser Wert ändert sich nicht, auch wenn der Name des Repositorys der Fall ist. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein
Build.Repository.Name	Der Name des auslösenden Repositorys. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	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-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein
Build.Repository.Tfvc.Workspace	Definiert, ob Ihr Repository der Team Foundation-Versionskontrolle unterliegt. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird. Wenn das Agent.BuildDirectory beispielsweise c:\agent_work\12 und die Agent.Id 8lautet, könnte der Arbeitsbereichsname ws_12_8 lauten. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	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-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein
Build.RequestedFor	Siehe 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	Siehe Wie werden die Identitätsvariablen festgelegt?.	Ja
Build.RequestedForId	Siehe 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 Wenn ein Tag Ihre Pipeline auslöst: 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/toolsist dieser Wert tools. In refs/tags/your-tag-nameist der Wert your_tag_name, mit Bindestrichen (-) ersetzt durch Unterstriche (_). 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 Bei selbst gehosteten Agents aktualisieren neue Buildpipelinen nur die geänderten Dateien. Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur. 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-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	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-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	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-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden. Außerdem ist diese Variable nur auf Schrittebene verfügbar und steht nicht in den Auftrags- oder Stufenebenen zur Verfügung. Das heißt, die Nachricht wird erst extrahiert, wenn der Auftrag gestartet wird und der Code ausgecheckt ist. Hinweis: Die Build.SourceVersionMessage- Variable funktioniert nicht mit klassischen Buildpipelinen in Bitbucket-Repositorys, wenn Batchänderungen vorgenommen werden, während ein Build ausgeführt wird, 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 Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur. 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-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein
Build.Repository.Git.SubmoduleCheckout	Der Wert, den Sie für Checkout-Untermodule ausgewählt haben, auf der Registerkarte Repository. Wenn mehrere Repos ausgecheckt sind, verfolgt dieser Wert die Einstellung des auslösenden Repositorys. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein
Build.SourceTfvcShelveset	Definiert, ob Ihr Repository der Team Foundation-Versionskontrolle unterliegt. Wenn Sie einen Gated Build oder ein Regalset-Buildausführen, wird diese Variable auf den Namen der Regalsets festgelegt, Sie erstellen. Hinweis: Diese Variable liefert einen Wert, der für die Buildverwendung in einem Buildnummernformat ungültig ist.	Nein
Build.TriggeredBy.BuildId	Wenn einen anderen Buildauslöser den Build auslöst, wird diese Variable auf die BuildID des auslösenden Builds festgelegt. In klassischen Pipelines löst ein Buildabschlusstrigger diese Variable aus. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden. Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.DefinitionId	Wenn einen anderen Buildtrigger Build auslöst, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt. In klassischen Pipelines löst ein Buildabschlusstrigger diese Variable aus. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden. Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.DefinitionName	Wenn einen anderen Buildtrigger Build auslöst, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. In klassischen Pipelines löst ein Buildabschlusstrigger diese Variable aus. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden. Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.BuildNumber	Wenn einem anderen Build Build ausgelöst wird, wird diese Variable auf die Nummer des auslösenden Builds festgelegt. In klassischen Pipelines löst ein Buildabschlusstrigger diese Variable aus. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden. Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.ProjectID	Wenn einen anderen Buildtrigger Build auslöst, wird diese Variable auf die ID des Projekts festgelegt, das den auslösenden Build enthält. In klassischen Pipelines löst ein Buildabschlusstrigger diese Variable aus. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden. 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 Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein

Pipelinevariablen

Variable	BESCHREIBUNG
Pipeline.Workspace	Arbeitsbereichsverzeichnis für eine bestimmte Pipeline. Diese Variable hat denselben Wert wie Agent.BuildDirectory. Beispiel: /home/vsts/work/1. Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur.

Tipp

Wenn Sie klassische Releasepipelines verwenden, können Sie klassische Versionen und Artefakte variablen verwenden,, um Daten in der gesamten Pipeline zu speichern und darauf zuzugreifen.

Bereitstellungsauftragsvariablen

Diese Variablen sind auf einen bestimmten Bereitstellungsauftrag festgelegt und werden nur 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. Beispielsweise bookings ein Kubernetes-Namespace, der der Umgebung als Ressource hinzugefügt wird, smarthotel-dev.
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

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

Variable	BESCHREIBUNG	In Vorlagen verfügbar?
System.AccessToken	Verwenden des OAuth-Tokens für den Zugriff auf die REST-API. Verwenden von System.AccessToken aus YAML-Skripts. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Ja
System.CollectionId	Die GUID der Azure DevOps-Organisation oder -Sammlung.	Ja
System.CollectionUri	Der URI der Azure DevOps-Organisation oder -Sammlung. 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 Weitere Informationen zur Agentverzeichnisstruktur finden Sie unter Agent-Verzeichnisstruktur. Bei selbst gehosteten Agents aktualisieren neue Buildpipelinen standardmäßig 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. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	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). Das Konzept der Phase wird hauptsächlich aus Azure-Pipelines entfernt. Matrix- und Multikonfigurationsaufträge sind der einzige Ort, an dem sich eine Phase 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 in einer YAML-Pipeline verfügbar, wenn sich eine Zweigrichtlinie auf die 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 in einer YAML-Pipeline verfügbar, wenn sich eine Zweigrichtlinie auf die 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 in einer YAML-Pipeline verfügbar, wenn sich eine Zweigrichtlinie auf die 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 in einer YAML-Pipeline verfügbar, wenn sich eine Zweigrichtlinie auf die 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 Azure DevOps-Organisation oder -Sammlung. Beispiel: https://dev.azure.com/fabrikamfiber/ Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	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	Wird auf True festgelegt, wenn eine Buildaufgabe das Skript ausführt. Diese Variable ist agent-bezogenen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden. Sie kann nicht als Teil der Buildnummer oder als Versionssteuerungstag verwendet werden.	Nein

Prüfvariablen (DevOps Services)

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

Wie werden die Identitätsvariablen festgelegt?

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

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

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.