Freigeben über


Verwenden vordefinierter Variablen

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

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

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

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

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

Erfahren Sie mehr über das Arbeiten mit Variablen.

Build.Clean

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

System.AccessToken

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

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

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

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

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.

    Festlegen des Systemdebuggings auf „true“

  4. Speichern Sie die neue Variable.

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

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

variables:
  system.debug: 'true'

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

Hinweis

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

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

Agent-Variablen (DevOps Services)

Hinweis

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

Variable BESCHREIBUNG
Agent.BuildDirectory Der lokale Pfad im Agent, in dem alle Ordner für eine bestimmte Buildpipeline erstellt werden. Diese Variable hat denselben Wert wie Pipeline.Workspace. Beispiel: /home/vsts/work/1
Agent.ContainerMapping Eine Zuordnung von Containerressourcennamen in YAML zu ihren Docker-IDs zur Laufzeit.

Die folgende Tabelle zeigt ein Beispiel.
Agent.HomeDirectory Das Verzeichnis, in dem der Agent installiert ist. Es enthält die Agent-Software. Beispiel: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobName Der Name des derzeit ausgeführten Auftrags. Dieser lautet in der Regel „Job“ oder „__default“, in Multikonfigurationsszenarien handelt es sich jedoch um die Konfiguration.
Agent.JobStatus Der Status des Builds.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)
  • Skipped (letzter Auftrag)
Auf die Umgebungsvariable sollte als AGENT_JOBSTATUS verwiesen werden. Der ältere agent.jobstatus ist aus Gründen der Abwärtskompatibilität verfügbar.
Agent.MachineName Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name Der Name des Agents, der im Pool registriert ist.

Wenn Sie einen selbstgehosteten Agent verwenden, wird dieser Name von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.
Agent.OS Das Betriebssystem des Agent-Hosts. Gültige Werte sind:
  • Windows_NT
  • Darwin
  • Linux
Bei Ausführung in einem Container können Agent-Host und Container unterschiedliche Betriebssysteme ausführen.
Agent.OSArchitecture Die Betriebssystem-Prozessorarchitektur des Agent-Hosts. Gültige Werte sind:
  • X86
  • X64
  • ARM
Agent.TempDirectory Ein temporärer Ordner, der nach jedem Pipelineauftrag bereinigt wird. Dieses Verzeichnis wird von Aufgaben wie der .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu speichern, bevor sie veröffentlicht werden.

Beispiel: /home/vsts/work/_temp für Ubuntu.
Agent.ToolsDirectory Das Verzeichnis, das von Aufgaben wie dem Node-Tool-Installer und Use Python Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln.

Diese Aufgaben fügen Tools aus diesem Verzeichnis zu PATH hinzu, damit nachfolgende Buildschritte sie verwenden können.

Erfahren Sie mehr über das Verwalten dieses Verzeichnisses in einem selbst gehosteten Agent.
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent.

Beispiel: c:\agent_work

Hinweis: Es ist nicht garantiert, dass Pipelineaufgaben in dieses Verzeichnis schreiben können (z. B. wenn es einem Container zugeordnet ist).

Beispiel für Agent.ContainerMapping:

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

Buildvariablen (DevOps Services)

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

Variable BESCHREIBUNG In Vorlagen verfügbar?
Build.ArtifactStagingDirectory Der lokale Pfad im Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden. Beispiel: c:\agent_work\1\a

Eine typische Verwendungsweise dieses Ordners besteht darin, Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte veröffentlichen zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind untereinander austauschbar. Dieses Verzeichnis wird vor jedem neuen Build bereinigt, Sie müssen den Bereinigungsvorgang also nicht selbst ausführen.

Weitere Informationen finden Sie unter Artefakte in Azure Pipelines.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.BuildId Die ID des Datensatzes für den abgeschlossenen Build. Nein
Build.BuildNumber Der Name des abgeschlossenen Builds, auch als Ausführungsnummer bezeichnet. Sie können angeben, was in diesem Wert enthalten ist.

Eine typische Verwendung dieser Variablen besteht darin, sie zu einem Teil des Bezeichnungsformats zu machen, das Sie auf der Registerkarte Repository angeben.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen tritt beim Bezeichnungsformat ein Fehler auf.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.BuildUri Der URI für den Build. Beispiel: vstfs:///Build/Build/1430.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.BinariesDirectory Der lokale Pfad im Agent, den Sie als Ausgabeordner für kompilierte Binärdateien verwenden können.

Standardmäßig sind neue Buildpipelines nicht so eingerichtet, dass dieses Verzeichnis bereinigt wird. Sie können Ihren Build auf der Registerkarte Repository so definieren, dass eine Bereinigung durchgeführt wird.

Beispiel: c:\agent_work\1\b.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.ContainerId Die ID des Containers für Ihr Artefakt. Wenn Sie ein Artefakt in Ihre Pipeline hochladen, wird es einem Container hinzugefügt, der speziell für dieses bestimmte Artefakt gilt. Nein
Build.CronSchedule.DisplayName Der displayName des Cron-Zeitplans, der die Pipelineausführung ausgelöst hat. Diese Variable wird nur festgelegt, wenn die Pipelineausführung durch einen geplanten YAML-Trigger ausgelöst wird. Weitere Informationen finden Sie unter schedules.cron definition – Build.CronSchedule.DisplayName-Variable Ja
Build.DefinitionName Der Name der Buildpipeline.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen tritt beim Bezeichnungsformat ein Fehler auf.
Ja
Build.DefinitionVersion Die Version der Buildpipeline. Ja
Build.QueuedBy Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen tritt beim Bezeichnungsformat ein Fehler auf.
Ja
Build.QueuedById Weitere Informationen finden Sie unter „Wie werden die Identitätsvariablen festgelegt?“. Ja
Build.Reason Das Ereignis, das die Ausführung des Builds verursacht hat.
  • Manual: Der Build wurde benutzerseitig manuell in die Warteschlange eingereiht.
  • IndividualCI: Continuous Integration (CI), ausgelöst durch einen Git-Push- oder TFVC-Check-In-Vorgang.
  • BatchedCI: Continuous Integration (CI), ausgelöst durch einen Git-Push- oder TFVC-Check-In-Vorgang, mit Auswahl von Batchänderungen.
  • Schedule: Geplanter Trigger.
  • ValidateShelveset: Der Build eines bestimmten TFVC-Shelvesets wurde benutzerseitig manuell in die Warteschlange eingereiht.
  • CheckInShelveset: Gated-Check-In-Trigger.
  • PullRequest: Der Build wurde durch eine Git-Branch-Richtlinie ausgelöst, die einen Build erfordert.
  • BuildCompletion: Der Build wurde durch einen anderen Build ausgelöst.
  • ResourceTrigger: Der Build wurde durch einen Ressourcentrigger oder durch einen anderen Build ausgelöst.
Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Branchrichtlinien.
Ja
Build.Repository.Clean Der Wert, den Sie für Clean in den Einstellungen des Quellrepositorys ausgewählt haben.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.LocalPath Der lokale Pfad im Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Auf der Registerkarte Repository können Sie ändern, auf welche Weise Dateien heruntergeladen werden.

Wichtiger Hinweis: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code.

Wenn Sie mehrere Repositorys auschecken, lautet das Verhalten wie folgt (und unterscheidet sich möglicherweise vom Wert der Build.SourcesDirectory-Variablen):
  • Wenn im Check-Out-Schritt für das (primäre) self-Repository (primär) kein benutzerdefinierter Check-Out-Pfad definiert ist oder der Check-Out-Pfad der Multi-Check-Out-Standardpfad $(Pipeline.Workspace)/s/&<RepoName> für das self-Repository ist, wird der Wert dieser Variablen auf den Standardwert zurückgesetzt: $(Pipeline.Workspace)/s.
  • Wenn im Check-Out-Schritt für das (primäre) self-Repository ein benutzerdefinierter Check-Out-Pfad definiert ist (und nicht der Multi-Check-Out-Standardpfad ist), enthält diese Variable den genauen Pfad zum self-Repository.
Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.ID Der eindeutige Bezeichner des Repositorys.

Dieser ändert sich nicht, auch wenn der Name des Repositorys sich ändert.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.Name Der Name des auslösenden Repositorys.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.Provider Der Typ des auslösenden Repositorys.
Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.Tfvc.Workspace Definiert, ob Ihr Repository der Team Foundation-Versionskontrolle unterliegt. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird.

Wenn das Agent.BuildDirectory beispielsweise c:\agent_work\12 und die Agent.Id 8lautet, könnte der Arbeitsbereichsname ws_12_8 lauten.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.Uri Die URL für das auslösende Repository. Beispiel:
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.
Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Ja
Build.SourceVersionMessage Der Kommentar des Commits oder des Changesets für das auslösende Repository. Wir kürzen die Meldung auf die erste Zeile bzw. 200 Zeichen, je nachdem, was kürzer ist.

Die Build.SourceVersionMessage entspricht der Meldung beim Build.SourceVersion-Commit. Der Build.SourceVersion-Commit für einen PR-Build ist der Mergecommit (nicht der Commit im Quellbranch).

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.

Außerdem ist diese Variable nur auf Schrittebene und nicht auf den Auftrags- oder Phasenebenen verfügbar (d. h. die Nachricht wird erst extrahiert, wenn der Auftrag gestartet wird und der Code ausgecheckt ist).

Hinweis: Diese Variable ist in TFS 2015.4 verfügbar.

Hinweis: Die Build.SourceVersionMessage-Variable funktioniert nicht mit klassischen Buildpipelines in Bitbucket-Repositorys, wenn Batchänderungen während der Durchführung eines Builds aktiviert ist.
Nein
Build.StagingDirectory Der lokale Pfad im Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden. Beispiel: c:\agent_work\1\a

Eine typische Verwendungsweise dieses Ordners besteht darin, Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte veröffentlichen zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind untereinander austauschbar. Dieses Verzeichnis wird vor jedem neuen Build bereinigt, Sie müssen den Bereinigungsvorgang also nicht selbst ausführen.

Weitere Informationen finden Sie unter Artefakte in Azure Pipelines.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.Git.SubmoduleCheckout Der Wert, den Sie auf der Registerkarte Repository für Submodule auschecken ausgewählt haben. Wenn mehrere Repositorys ausgecheckt sind, verfolgt dieser Wert die Einstellung des auslösenden Repositorys nach.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.SourceTfvcShelveset Definiert, ob Ihr Repository der Team Foundation-Versionskontrolle unterliegt.

Wenn Sie einen Gated-Build oder einen Shelvesetbuild ausführen, ist dies auf den Namen des Shelvesets festgelegt, das Sie erstellen.

Hinweis: Diese Variable liefert einen Wert, der für die Buildverwendung in einem Buildnummernformat ungültig ist.
Nein
Build.TriggeredBy.BuildId Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die BuildID des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.

Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.
Nein
Build.TriggeredBy.DefinitionId Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.

Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.
Nein
Build.TriggeredBy.DefinitionName Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.

Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.
Nein
Build.TriggeredBy.BuildNumber Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die Nummer des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.

Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.
Nein
Build.TriggeredBy.ProjectID Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die ID des Projekts festgelegt, das den auslösenden Build enthält. In klassischen Pipelines wird diese Variable durch einen Trigger für den Buildabschluss ausgelöst.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.

Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.
Nein
Common.TestResultsDirectory Der lokale Pfad im Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein

Pipelinevariablen (DevOps Services)

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

Tipp

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

Variablen für Bereitstellungsaufträge (DevOps Services)

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

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

Systemvariablen (DevOps Services)

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

Variable BESCHREIBUNG In Vorlagen verfügbar?
System.AccessToken Verwenden des OAuth-Tokens für den Zugriff auf die REST-API.

Verwenden von System.AccessToken aus YAML-Skripts.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Ja
System.CollectionId Die GUID der TFS-Sammlung oder Azure DevOps-Organisation. Ja
System.CollectionUri Der URI der TFS-Sammlung oder Azure DevOps-Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/. Ja
System.DefaultWorkingDirectory Der lokale Pfad im Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Auf der Registerkarte Repository können Sie ändern, auf welche Weise Dateien heruntergeladen werden.

Diese Variable ist Agent-bezogen. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Ja
System.DefinitionId Die ID der Buildpipeline. Ja
System.HostType Auf build festgelegt, wenn die Pipeline ein Build ist. Bei einem Release lauten die Werte deployment für einen Bereitstellungsgruppenauftrag, gates während der Auswertung von Gates und release für andere Aufträge (mit oder ohne Agent). Ja
System.JobAttempt Auf 1 festgelegt, wenn die Ausführung des Auftrags zum ersten Mal versucht wird, erhöht sich bei jedem neuen Versuch, den Auftrag auszuführen. Nein
System.JobDisplayName Der für Menschen lesbare Name eines Auftrags. Nein
System.JobId Ein eindeutiger Bezeichner für einen einzelnen Versuch eines einzelnen Auftrags. Der Wert ist für die aktuelle Pipeline eindeutig. Nein
System.JobName Der Name des Auftrags, wird in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet. No
System.OidcRequestUri Generieren Sie ein ID-Token (idToken) für die Authentifizierung mit Entra ID mithilfe von OpenID Connect (OIDC). Weitere Informationen Ja
System.PhaseAttempt Auf 1 festgelegt, wenn die Phase zum ersten Mal versucht wird, erhöht sich bei jedem neuen Versuch, den Auftrag auszuführen.

Hinweis: „Phase“ ist ein weitgehend redundantes Konzept, das die Entwurfszeit für einen Auftrag darstellt (während ein Auftrag die Laufzeitversion einer Phase war). Wir haben das Konzept der Phasen größtenteils aus Azure Pipelines entfernt. Matrix- und Multikonfigurationsaufträge sind die einzige Stelle, an der eine „Phase“ sich noch von einem „Auftrag“ unterscheidet. Eine Phase kann mehrere Aufträge instanziieren, die sich nur in ihren Eingaben unterscheiden.
Nein
System.PhaseDisplayName Der für Menschen lesbare Name einer Phase. Nein
System.PhaseName Ein zeichenfolgenbasierter Bezeichner für einen Auftrag, wird in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet. Nein
System.PlanId Ein zeichenfolgenbasierter Bezeichner für eine einzelne Pipelineausführung. Nein
System.PullRequest.IsFork Wenn der Pull Request aus einem Fork des Repositorys stammt, wird diese Variable auf True festgelegt.

Andernfalls ist sie auf False festgelegt.
Ja
System.PullRequest.PullRequestId Die ID des Pull Requests, der diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt). Nein
System.PullRequest.PullRequestNumber Die Nummer des Pull Requests, der diesen Build verursacht hat. Diese Variable wird für Pull Requests von GitHub aufgefüllt, die eine andere Pull Request-ID und Pull Request-Nummer aufweisen. Diese Variable ist nur dann in einer YAML-Pipeline verfügbar, wenn sich eine Branchrichtlinie auf den PR auswirkt. Nein
System.PullRequest.targetBranchName Der Name des Zielbranchs für einen Pull Request. Diese Variable kann in einer Pipeline verwendet werden, um Aufgaben oder Schritte basierend auf dem Zielbranch des Pull Requests bedingt auszuführen. Sie können z. B. je nach Branch, in den die Änderungen gemergt werden, eine andere Reihe von Tests oder Codeanalysetools auslösen. Nein
System.PullRequest.SourceBranch Der Branch, der in einem Pull Request überprüft wird. Beispiel: refs/heads/users/raisa/new-feature für Azure Repos. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt). Diese Variable ist nur dann in einer YAML-Pipeline verfügbar, wenn sich eine Branchrichtlinie auf den PR auswirkt. Nein
System.PullRequest.SourceCommitId Der Commit, der in einem Pull Request überprüft wird. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt). Diese Variable ist nur dann in einer YAML-Pipeline verfügbar, wenn sich eine Branchrichtlinie auf den PR auswirkt.
System.PullRequest.SourceRepositoryURI Die URL zu dem Repository, das den Pull Request enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject. Nein
System.PullRequest.TargetBranch Der Branch, der Ziel eines Pull Requests ist. Beispiel: refs/heads/main, wenn sich Ihr Repository in Azure Repos befindet, und main, wenn sich Ihr Repository in GitHub befindet. Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR ausgeführt wurde, auf den sich eine Branchrichtlinie auswirkt. Diese Variable ist nur dann in einer YAML-Pipeline verfügbar, wenn sich eine Branchrichtlinie auf den PR auswirkt. Nein
System.StageAttempt Auf 1 festgelegt, wenn die Stage zum ersten Mal versucht wird, erhöht sich bei jedem neuen Versuch, den Auftrag auszuführen. Nein
System.StageDisplayName Der für Menschen lesbare Name einer Stage. Nein
System.StageName Ein zeichenfolgenbasierter Bezeichner für eine Stage, wird in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet. Nein
System.TeamFoundationCollectionUri Der URI der TFS-Sammlung oder Azure DevOps-Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Ja
System.TeamProject Der Name des Projekts, das diesen Build enthält. Ja
System.TeamProjectId Die ID des Projekts, zu dem dieser Build gehört. Ja
System.TimelineId Ein zeichenfolgenbasierter Bezeichner für die Ausführungsdetails und Protokolle einer einzelnen Pipelineausführung. Nein
TF_BUILD Auf True festgelegt, wenn das Skript von einer Buildaufgabe ausgeführt wird.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein

Prüfvariablen (DevOps Services)

Variable BESCHREIBUNG
Checks.StageAttempt Auf 1 festgelegt, wenn die Stage zum ersten Mal versucht wird, erhöht sich bei jedem neuen Versuch, die Stage auszuführen.

Diese Variable kann nur im Rahmen einer Genehmigung oder Überprüfung für eine Umgebung verwendet werden. Sie können $(Checks.StageAttempt) z. B. beim Aufruf einer REST-API-Überprüfung verwenden.

Fügen Sie Stage.Attempt als Parameter hinzu.

Agent-Variablen (DevOps Server 2022)

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

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. 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.
Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.Tfvc.Workspace Definiert, ob Ihr Repository der Team Foundation-Versionskontrolle unterliegt. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird.

Wenn das Agent.BuildDirectory beispielsweise c:\agent_work\12 und die Agent.Id 8lautet, könnte der Arbeitsbereichsname ws_12_8 lauten:

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.Uri Die URL für das auslösende Repository. Beispiel: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.
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)

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

Variable BESCHREIBUNG In Vorlagen verfügbar?
System.AccessToken Verwenden des OAuth-Tokens für den Zugriff auf die REST-API.

Verwenden von System.AccessToken aus YAML-Skripts.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Ja
System.CollectionId Die GUID der TFS-Sammlung oder Azure DevOps-Organisation. Ja
System.CollectionUri Der URI der TFS-Sammlung oder Azure DevOps-Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/. Ja
System.DefaultWorkingDirectory Der lokale Pfad im Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Auf der Registerkarte Repository können Sie ändern, auf welche Weise Dateien heruntergeladen werden.

Diese Variable ist Agent-bezogen. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Ja
System.DefinitionId Die ID der Buildpipeline. Ja
System.HostType Auf build festgelegt, wenn die Pipeline ein Build ist. Bei einem Release lauten die Werte deployment für einen Bereitstellungsgruppenauftrag, gates während der Auswertung von Gates und release für andere Aufträge (mit oder ohne Agent). Ja
System.JobAttempt Auf 1 festgelegt, wenn die Ausführung des Auftrags zum ersten Mal versucht wird, erhöht sich bei jedem neuen Versuch, den Auftrag auszuführen. Nein
System.JobDisplayName Der für Menschen lesbare Name eines Auftrags. Nein
System.JobId Ein eindeutiger Bezeichner für einen einzelnen Versuch eines einzelnen Auftrags. Der Wert ist für die aktuelle Pipeline eindeutig. Nein
System.JobName Der Name des Auftrags, wird in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet. 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. No
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.
Fügen Sie Stage.Attempt als Parameter hinzu.

Agent-Variablen (DevOps Server 2020)

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

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.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/&lt;RepoName&gt; 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.
Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.Tfvc.Workspace Definiert, ob Ihr Repository der Team Foundation-Versionskontrolle unterliegt. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird.

Wenn das Agent.BuildDirectory beispielsweise c:\agent_work\12 und die Agent.Id 8lautet, könnte der Arbeitsbereichsname ws_12_8 lauten:

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Nein
Build.Repository.Uri Die URL für das auslösende Repository. Beispiel:
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.
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)

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

Variable BESCHREIBUNG In Vorlagen verfügbar?
System.AccessToken Verwenden des OAuth-Tokens für den Zugriff auf die REST-API.

Verwenden von System.AccessToken aus YAML-Skripts.

Diese Variable ist Agent-bezogen und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, nicht jedoch als Teil der Buildnummer oder als Versionskontrolltag.
Ja
System.CollectionId Die GUID der TFS-Sammlung oder Azure DevOps-Organisation. Ja
System.CollectionUri 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

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. 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.
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 8lautet, 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:
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.
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