Verwenden vordefinierter Variablen

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

Variablen bieten Ihnen eine bequeme Möglichkeit, wichtige Datenbits in verschiedene Teile Ihrer Pipeline zu erhalten. Dies ist eine Liste vordefinierter Variablen, die für Ihre Verwendung verfügbar sind. Möglicherweise gibt es einige andere vordefinierte Variablen, aber sie sind hauptsächlich für interne Verwendung.

Diese Variablen werden automatisch vom System und schreibgeschützt festgelegt. (Die Ausnahmen sind Build.Clean und System.Debug.)

In YAML-Pipelines können Sie vordefinierte Variablen als Umgebungsvariablen verweisen. Die Variable wird z. B. zur Variablen Build.ArtifactStagingDirectoryBUILD_ARTIFACTSTAGINGDIRECTORY.

Bei klassischen Pipelines können Sie Freigabevariablen in Ihren Bereitstellungsaufgaben verwenden, um die allgemeinen Informationen (z. B. — Umgebungsname, Ressourcengruppe usw.) freizugeben.

Erfahren Sie mehr über das Arbeiten mit Variablen.

Build.Clean

Dies ist eine veraltete Variable, die ändert, wie der Build-Agent die Quelle bereinigt. Informationen zum Bereinigen der Quelle finden Sie unter Bereinigen des lokalen Repo für den Agent.

System.AccessToken

System.AccessToken ist eine spezielle Variable, die das sicherheitstoken enthält, das vom ausgeführten Build verwendet wird.

YAML

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

steps:
  - bash: echo This script could use $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: | 
      Write-Host "This is a script that could use $env:SYSTEM_ACCESSTOKEN"
      Write-Host "$env:SYSTEM_ACCESSTOKEN = $(System.AccessToken)"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Sie können den Standardbereich für System.AccessToken die Verwendung des Buildauftragsberechtigungsbereichs konfigurieren.

Klassisch

Sie können Skripts und Aufgaben auf System.AccessToken auf Jobebene zugreifen.

1. Navigieren zum Auftrag

2. Aktivieren Sie unter "Zusätzliche Optionen" die Skripts, um auf das OAuth-Token zuzugreifen .

Wenn Sie dieses Kontrollkästchen aktivieren, wird auch der Anmeldeinformationensatz in Git verlassen, sodass Sie Pushs und Pulls in Ihren Skripts ausführen können.

System.Debug

Ausführlichere Protokolle zum Debuggen von Pipelineproblemen, definieren und festlegen System.Debug sie auf true.

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

   

4. Speichern Sie die neue Variable.

Agentvariablen (DevOps Services)

Hinweis

Sie können Agentvariablen als Umgebungsvariablen in Ihren Skripts und als Parameter in Ihren Buildaufgaben verwenden. Sie können sie nicht verwenden, um die Buildnummer anzupassen oder eine Versionssteuerungsbezeichnung oder ein Tag anzuwenden.

Variable	BESCHREIBUNG
Agent.BuildDirectory	Der lokale Pfad im Agent, in dem alle Ordner für eine bestimmte Buildpipeline erstellt werden. Diese Variable hat denselben Wert wie Pipeline.Workspace. Beispiel: /home/vsts/work/1
Agent.ContainerMapping	Eine Zuordnung von Containerressourcennamen in YAML zu ihren Docker-IDs zur Laufzeit. Beispiel: { "one_container": { "id": "bdbb357d73a0bd3550a1a5b778b62a4c88ed2051c7802a0659f1ff6e76910190" }, "another_container": { "id": "82652975109ec494876a8ccbb875459c945982952e0a72ad74c91216707162bb" } }
Agent.HomeDirectory	Das Verzeichnis, in das der Agent installiert ist. Dies enthält die Agentsoftware. Beispiel: c:\agent.
Agent.Id	Die ID der Momentaufnahme.
Agent.JobName	Der Name des ausgeführten Auftrags. Dies ist in der Regel "Auftrag" oder "__default", aber in multikonfigurationsszenarien ist die Konfiguration.
Agent.JobStatus	Der Status des Builds. Canceled Failed Succeeded SucceededWithIssues (teilweise erfolgreich) Die Umgebungsvariable sollte als AGENT_JOBSTATUSreferenziert werden. Die ältere agent.jobstatus ist für die Abwärtskompatibilität verfügbar.
Agent.MachineName	Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name	Der Name des Agent, der mit dem Pool registriert ist. Wenn Sie einen selbst gehosteten Agent verwenden, wird dieser Name von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.
Agent.OS	Das Betriebssystem des Agenthosts. Gültige Werte sind: Windows_NT Darwin Linux Wenn Sie in einem Container ausgeführt werden, kann der Agenthost und der Container verschiedene Betriebssysteme ausführen.
Agent.OSArchitecture	Die Betriebssystemprozessorarchitektur des Agenthosts. 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 .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu halten, bevor sie veröffentlicht werden. Beispiel: /home/vsts/work/_temp für Ubuntu
Agent.ToolsDirectory	Das Verzeichnis, das von Aufgaben wie 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 PATH hinzu, damit nachfolgende Buildschritte sie verwenden können. Erfahren Sie mehr über das Verwalten dieses Verzeichnisses auf einem selbst gehosteten Agent.
Agent.WorkFolder	Das Arbeitsverzeichnis für diesen Agent. Beispiel: c:\agent_work. Hinweis: Dieses Verzeichnis ist nicht garantiert, dass sie von Pipelineaufgaben (z. B. beim Zugeordneten in einen Container) geschrieben werden kann.

Buildvariablen (DevOps Services)

Variable	BESCHREIBUNG	In Vorlagen verfügbar?
Build.ArtifactStagingDirectory	Der lokale Pfad auf dem Agent, in dem alle Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen" zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, damit Sie es nicht selbst bereinigen müssen. Siehe Artifacts in Azure Pipelines. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Build.BuildId	Die ID des Datensatzes für den abgeschlossenen Build.	Nein
Build.BuildNumber	Der Name des abgeschlossenen Builds, auch bekannt als Die Ausführungsnummer. Sie können angeben , was in diesem Wert enthalten ist. Eine typische Verwendung dieser Variablen besteht darin, es teil des Bezeichnungsformats zu machen, das Sie auf der Repositoryregisterkarte angeben. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.BuildUri	Der URI für den Build. Beispiel: vstfs:///Build/Build/1430. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.BinariesDirectory	Der lokale Pfad für den Agent, den Sie als Ausgabeordner für kompilierte Binärdateien verwenden können. Standardmäßig sind neue Buildpipelinen nicht zum Bereinigen dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um sie auf der Registerkarte "Repository" zu bereinigen. Beispiel: c:\agent_work\1\b. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.ContainerId	Die ID des Containers für Ihr Artefakte. Wenn Sie ein Artefakte in Ihrer Pipeline hochladen, wird es einem Container hinzugefügt, der für dieses bestimmte Artefakt spezifisch ist.	Nein
Build.DefinitionName	Der Name der Buildpipeline. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.	Ja
Build.DefinitionVersion	Die Version der Buildpipeline.	Ja
Build.QueuedBy	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.	Ja
Build.QueuedById	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.	Ja
Build.Reason	Das Ereignis, das dazu führte, dass der Build ausgeführt wurde. Manual: Ein Benutzer hat den Build manuell in die Warteschlange gestellt. IndividualCI: Kontinuierliche Integration (CI), die von einem Git-Push oder einem TFVC-Check-In ausgelöst wird. BatchedCI: Kontinuierliche Integration (CI), die von einem Git-Push oder einer TFVC-Überprüfung ausgelöst wird, und die Batchänderungen wurden ausgewählt. Schedule: Geplanter Trigger. ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Regales manuell in die Warteschlange gestellt. CheckInShelveset: Gated Check-In-Trigger . PullRequest: Der Build wurde von einer Git-Verzweigungsrichtlinie ausgelöst, die einen Build erfordert. ResourceTrigger: Der Build wurde durch einen Ressourcenauslöser ausgelöst oder durch einen anderen Build ausgelöst. Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Verzweigungsrichtlinien.	Ja
Build.Repository.Clean	Der Wert, den Sie für "Bereinigen " in den Quell-Repositoryeinstellungen ausgewählt haben. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.LocalPath	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Wichtig: 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 der Auscheckschritt für das Selbst-Repository (primär) keinen benutzerdefinierten Auscheckpfad definiert hat, oder der Auscheckpfad der Standardpfad $(Pipeline.Workspace)/s/<RepoName> für das Self-Repository ist, wird der Wert dieser Variable auf den Standardwert zurückgesetzt.$(Pipeline.Workspace)/s Wenn der Auscheckschritt für das Selbst-Repository (primär) einen benutzerdefinierten Auscheckpfad definiert hat (und nicht der Standardpfad mit mehreren Auscheckvorgängen ist), enthält diese Variable den genauen Pfad zum Self-Repository. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.ID	Der eindeutige Bezeichner des Repositorys. Dies ändert sich nicht, auch wenn der Name des Repositorys erfolgt. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.Name	Der Name des auslösenden Repositorys. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.Provider	Der Typ des auslösenden Repositorys. TfsGit: TFS Git Repository TfsVersionControl: Team Foundation-Versionskontrolle Git: Git-Repository, das auf einem externen Server gehostet wird GitHub Svn: Subversion Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.Tfvc.Workspace	Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Der Name des TFVC-Arbeitsbereichs , der vom Build-Agent verwendet wird. Wenn z. B. "Agent.BuildDirectory c:\agent_work\12 " und "Agent.Id" lautet 8, könnte der Arbeitsbereichsname folgendes sein: ws_12_8 Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.Uri	Die URL für das auslösende Repository. Beispiel: Git: https://dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.RequestedFor	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.	Ja
Build.RequestedForEmail	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.	Ja
Build.RequestedForId	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.	Ja
Build.SourceBranch	Der Zweig des auslösenden Repo, für das der Build in die Warteschlange gestellt wurde. Einige Beispiele: Git-Repo-Verzweigung: refs/heads/master Git-Repo-Pullanforderung: refs/pull/1/merge TFVC-Repo-Verzweigung: $/teamproject/main TFVC-Repo-Check-In: Gated_2016-06-06_05.20.51.4369;username@live.com TFVC-Repo-Regale erstellen: myshelveset;username@live.com Wenn Ihre Pipeline durch ein Tag ausgelöst wird: refs/tags/your-tag-name Wenn Sie diese Variable im Buildnummernformat verwenden, werden die Schrägstrichzeichen (/) durch Unterstriche _ersetzt). Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.	Ja
Build.SourceBranchName	Der Name der Verzweigung im auslösenden Repo, für das der Build in die Warteschlange gestellt wurde. Git repo branch or pull request: The last path segment in the ref. In diesem Wert ist masterz. Brefs/heads/master. . In refs/heads/feature/tools diesem Wert ist tools. TFVC-Repo-Verzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert ist mainz. B$/teamproject/main. . TFVC Repo gated Check-In oder Regalet Build ist der Name des Regals. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com. Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.	Ja
Build.SourcesDirectory	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Wichtig: 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)/sauch dann ausgecheckt wird, wenn das Selbstrepository auf einen benutzerdefinierten Pfad ausgecheckt wird, der sich von seinem Standardpfad $(Pipeline.Workspace)/s/<RepoName> mit mehreren Auscheckvorgängen unterscheidet (in diesem Zusammenhang unterscheidet sich die Variable vom Verhalten der Variable Build.Repository.LocalPath). Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.SourceVersion	Die neueste Versionssteuerungsänderung des auslösenden Repo, das in diesem Build enthalten ist. Git: Die Commit-ID . TFVC: das Changeset. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Ja
Build.SourceVersionMessage	Der Kommentar des Commits oder des Änderungssets für das auslösende Repo. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen, je nachdem, was kürzer ist. Dies Build.SourceVersionMessage entspricht der Nachricht beim Build.SourceVersion Commit. Der Build.SourceVersion Commit für einen PR-Build ist der Merge Commit (nicht der Commit für den Quellzweig). Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Außerdem ist diese Variable nur auf Schrittebene verfügbar und steht weder in der Auftrags- noch in Phasenebene zur Verfügung (d. h. die Nachricht wird erst extrahiert, wenn der Auftrag gestartet und den Code ausgecheckt hat). Hinweis: Diese Variable ist in TFS 2015.4 verfügbar.	Nein
Build.StagingDirectory	Der lokale Pfad auf dem Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen " zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen. Siehe Artifacts in Azure Pipelines. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.Git.SubmoduleCheckout	Der Wert, den Sie für Untermodule auschecken auf der Registerkarte "Repository" ausgewählt haben. Wenn mehrere Repos ausgecheckt sind, verfolgt dieser Wert die Einstellung des auslösenden Repositorys. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.SourceTfvcShelveset	Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Wenn Sie einen gated Build oder einen Regalet-Build ausführen, wird dies auf den Namen der Regale festgelegt, die Sie erstellen. Hinweis: Diese Variable gibt einen Wert zurück, der für die Buildverwendung in einem Buildnummernformat ungültig ist.	Nein
Build.TriggeredBy.BuildId	Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die BuildID des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildvervollständigen-Trigger ausgelöst. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Wenn Sie eine YAML-Pipeline mithilfe resourceseiner YAML-Pipeline auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.DefinitionId	Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildvervollständigen-Trigger ausgelöst. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Wenn Sie eine YAML-Pipeline mithilfe resourceseiner YAML-Pipeline auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.DefinitionName	Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildvervollständigen-Trigger ausgelöst. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Wenn Sie eine YAML-Pipeline mithilfe resourceseiner YAML-Pipeline auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.BuildNumber	Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die Anzahl des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildvervollständigen-Trigger ausgelöst. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Wenn Sie eine YAML-Pipeline mithilfe resourceseiner YAML-Pipeline auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Build.TriggeredBy.ProjectID	Wenn der Build von einem 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 Build-Abschlussauslöser ausgelöst. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag. Wenn Sie eine YAML-Pipeline mithilfe resourcesvon YAML auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.	Nein
Common.TestResultsDirectory	Der lokale Pfad auf dem Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein

Pipelinevariablen (DevOps Services)

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

Bereitstellungsauftragsvariablen (DevOps Services)

Diese Variablen sind auf einen bestimmten Bereitstellungsauftrag festgelegt und werden nur zu Auftragsausführungszeit aufgelöst.

Variable	BESCHREIBUNG
Environment.Name	Name der Umgebung, die im Bereitstellungsauftrag ausgerichtet ist, um die Bereitstellungsschritte auszuführen und den Bereitstellungsverlauf aufzuzeichnen. Beispiel: smarthotel-dev.
Environment.Id	ID der Umgebung, die im Bereitstellungsauftrag ausgerichtet ist. Beispiel: 10.
Environment.ResourceName	Name der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag ausgerichtet ist, um die Bereitstellungsschritte auszuführen und den Bereitstellungsverlauf aufzuzeichnen. So ist z. B bookings . ein Kubernetes-Namespace, der der Umgebung smarthotel-devals Ressource hinzugefügt wurde.
Environment.ResourceId	ID der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag zum Ausführen der Bereitstellungsschritte ausgerichtet ist. Beispiel: 4.
Strategy.Name	Der Name der Bereitstellungsstrategie: canary, oder runOncerolling.
Strategy.CycleName	Der aktuelle Zyklusname in einer Bereitstellung. Optionen sind PreIteration, oder IterationPostIteration.

Systemvariablen (DevOps Services)

Variable	BESCHREIBUNG	In Vorlagen verfügbar?
System.AccessToken	Verwenden Sie das OAuth-Token, um auf die REST-API zuzugreifen. Verwenden Sie System.AccessToken aus YAML-Skripts. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Ja
System.CollectionId	Die GUID der TFS-Auflistung oder Azure DevOps Organisation.	Ja
System.CollectionUri	Der URI der TFS-Auflistung oder Azure DevOps Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/.	Ja
System.DefaultWorkingDirectory	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Ja
System.DefinitionId	Die ID der Buildpipeline.	Ja
System.HostType	Legen Sie fest build , ob die Pipeline ein Build ist. Für eine Version sind deployment die Werte für einen Bereitstellungsgruppenauftrag, gates während der Auswertung von Gates und release für andere (Agent- und Agentless)-Aufträge.	Ja
System.JobAttempt	Legen Sie auf 1 fest, wenn dieser Auftrag zum ersten Mal versucht wird, und erhöhen Sie jedes Mal, wenn der Auftrag erneut bearbeitet wird.	Nein
System.JobDisplayName	Der menschenlesbare Name, der einem Auftrag zugewiesen wird.	Nein
System.JobId	Ein eindeutiger Bezeichner für einen einzelnen Versuch eines einzelnen Auftrags. Der Wert ist eindeutig für die aktuelle Pipeline.	Nein
System.JobName	Der Name des Auftrags, der in der Regel zum Ausdruck von Abhängigkeiten und zum Zugriff auf Ausgabevariablen verwendet wird.	Nein
System.PhaseAttempt	Legen Sie zum ersten Mal fest, dass diese Phase versucht wird, und erhöhen Sie jedes Mal, wenn der Auftrag erneut ausgeführt wird. Hinweis: "Phase" ist ein meist redundantes Konzept, das die Entwurfszeit für einen Auftrag darstellt (während der Auftrag die Laufzeitversion einer Phase war). Wir haben hauptsächlich das Konzept der "Phase" aus Azure Pipelines entfernt. Matrix- und Multikonfigurationsaufträge sind der einzige Ort, an dem sich "Phase" immer noch von "Job" unterscheidet. Eine Phase kann mehrere Aufträge instanziieren, die sich nur in ihren Eingaben unterscheiden.	Nein
System.PhaseDisplayName	Der menschliche lesbare Name, der einer Phase zugewiesen wird.	Nein
System.PhaseName	Ein Zeichenfolgenbasierter Bezeichner für einen Auftrag, der in der Regel zum Ausdruck von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet wird.	Nein
System.StageAttempt	Legen Sie zum ersten Mal fest, dass diese Phase versucht wird, und erhöht jedes Mal, wenn der Auftrag erneut bearbeitet wird.	Nein
System.StageDisplayName	Der menschlesbare Name, der einer Stufe zugewiesen wird.	Nein
System.StageName	Ein Zeichenfolgenbasierter Bezeichner für eine Phase, die in der Regel zum Ausdruck von Abhängigkeiten und zum Zugriff auf Ausgabevariablen verwendet wird.	Ja
System.PullRequest.IsFork	Wenn die Pullanforderung von einer Freihand des Repositorys stammt, wird diese Variable auf True"festgelegt" festgelegt. Andernfalls ist er auf False".	Ja
System.PullRequest.PullRequestId	Die ID der Pullanforderung, die diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist).	Nein
System.PullRequest.PullRequestNumber	Die Anzahl der Pull-Anforderung, die diesen Build verursacht hat. Diese Variable wird für Pullanforderungen aus GitHub ausgefüllt, die eine andere Pull-Anforderungs-ID und Eine Pull-Anforderungsnummer aufweisen. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Zweigrichtlinie betroffen ist.	Nein
System.PullRequest.SourceBranch	Die Verzweigung, die in einer Pullanforderung überprüft wird. Beispiel: refs/heads/users/raisa/new-feature für Azure Repos. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist). Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Zweigrichtlinie betroffen ist.	Nein
System.PullRequest.SourceRepositoryURI	Die URL zum Repo, das die Pullanforderung enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject.	Nein
System.PullRequest.TargetBranch	Der Zweig, der das Ziel einer Pullanforderung ist. Beispiel: refs/heads/master Wenn sich Ihr Repository in Azure Repos befindet und master sich Ihr Repository in GitHub befindet. Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Zweigrichtlinie betroffen ist.	Nein
System.TeamFoundationCollectionUri	Der URI der TFS-Auflistung oder Azure DevOps Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	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	True Legen Sie fest, ob das Skript von einer Buildaufgabe ausgeführt wird. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein

Überprüft Variablen (DevOps Services)

Variable	BESCHREIBUNG
Checks.StageAttempt	Legen Sie auf 1 fest, wenn diese Phase zum ersten Mal versucht wird, und erhöht jedes Mal, wenn die Phase erneut ausgeführt wird. Diese Variable kann nur innerhalb einer Genehmigung oder Überprüfung für eine Umgebung verwendet werden. Sie können z. B. innerhalb einer Aufruf-REST-API-Überprüfung verwenden$(Checks.StageAttempt).

Agentvariablen (DevOps Server 2020)

Hinweis

Sie können Agentvariablen als Umgebungsvariablen in Ihren Skripts und als Parameter in Ihren Buildaufgaben verwenden. Sie können sie nicht verwenden, um die Buildnummer anzupassen oder eine Versionssteuerungsbezeichnung oder ein Tag anzuwenden.

Variable	BESCHREIBUNG
Agent.BuildDirectory	Der lokale Pfad im Agent, in dem alle Ordner für eine bestimmte Buildpipeline erstellt werden. Diese Variable hat denselben Wert wie Pipeline.Workspace. Beispiel: /home/vsts/work/1
Agent.HomeDirectory	Das Verzeichnis, in das der Agent installiert ist. Dies enthält die Agentsoftware. Beispiel: c:\agent.
Agent.Id	Die ID der Momentaufnahme.
Agent.JobName	Der Name des ausgeführten Auftrags. Dies ist in der Regel "Auftrag" oder "__default", aber in multikonfigurationsszenarien ist die Konfiguration.
Agent.JobStatus	Der Status des Builds. Canceled Failed Succeeded SucceededWithIssues (teilweise erfolgreich) Die Umgebungsvariable sollte als AGENT_JOBSTATUSreferenziert werden. Die ältere agent.jobstatus ist für die Abwärtskompatibilität verfügbar.
Agent.MachineName	Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name	Der Name des Agent, der mit dem Pool registriert ist. Wenn Sie einen selbst gehosteten Agent verwenden, wird dieser Name von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.
Agent.OS	Das Betriebssystem des Agenthosts. Gültige Werte sind: Windows_NT Darwin Linux Wenn Sie in einem Container ausgeführt werden, kann der Agenthost und der Container verschiedene Betriebssysteme ausführen.
Agent.OSArchitecture	Die Betriebssystemprozessorarchitektur des Agenthosts. 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 .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu halten, bevor sie veröffentlicht werden. Beispiel: /home/vsts/work/_temp für Ubuntu
Agent.ToolsDirectory	Das Verzeichnis, das von Aufgaben wie Node Tool Installer und Python-Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis PATH hinzu, damit nachfolgende Buildschritte sie verwenden können. Erfahren Sie mehr über das Verwalten dieses Verzeichnisses auf einem selbst gehosteten Agent.
Agent.WorkFolder	Das Arbeitsverzeichnis für diesen Agent. Beispiel: c:\agent_work. Hinweis: Dieses Verzeichnis ist nicht garantiert, dass durch Pipelineaufgaben geschrieben werden kann (z. B. wenn ein Container zugeordnet wird)

Buildvariablen (DevOps Server 2020)

Variable	BESCHREIBUNG	Verfügbar in Vorlagen?
Build.ArtifactStagingDirectory	Der lokale Pfad auf dem Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen " zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen. Siehe Artifacts in Azure Pipelines. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.BuildId	Die ID des Datensatzes für den abgeschlossenen Build.	Nein
Build.BuildNumber	Der Name des abgeschlossenen Builds, auch bekannt als Die Ausführungsnummer. Sie können angeben , was in diesem Wert enthalten ist. Eine typische Verwendung dieser Variablen besteht darin, es teil des Bezeichnungsformats zu machen, das Sie auf der Repositoryregisterkarte angeben. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.BuildUri	Der URI für den Build. Beispiel: vstfs:///Build/Build/1430. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.BinariesDirectory	Der lokale Pfad für den Agent, den Sie als Ausgabeordner für kompilierte Binärdateien verwenden können. Standardmäßig sind neue Buildpipelinen nicht zum Bereinigen dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um sie auf der Registerkarte "Repository" zu bereinigen. Beispiel: c:\agent_work\1\b. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.ContainerId	Die ID des Containers für Ihr Artefakte. Wenn Sie ein Artefakte in Ihrer Pipeline hochladen, wird es einem Container hinzugefügt, der für dieses bestimmte Artefakt spezifisch ist.	Nein
Build.DefinitionName	Der Name der Buildpipeline. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.	Ja
Build.DefinitionVersion	Die Version der Buildpipeline.	Ja
Build.QueuedBy	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.	Ja
Build.QueuedById	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.	Ja
Build.Reason	Das Ereignis, das dazu führte, dass der Build ausgeführt wurde. Manual: Ein Benutzer hat den Build manuell in die Warteschlange gestellt. IndividualCI: Kontinuierliche Integration (CI), die von einem Git-Push oder einem TFVC-Check-In ausgelöst wird. BatchedCI: Kontinuierliche Integration (CI), die von einem Git-Push oder einer TFVC-Überprüfung ausgelöst wird, und die Batchänderungen wurden ausgewählt. Schedule: Geplanter Trigger. ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Regales manuell in die Warteschlange gestellt. CheckInShelveset: Gated Check-In-Trigger . PullRequest: Der Build wurde von einer Git-Verzweigungsrichtlinie ausgelöst, die einen Build erfordert. ResourceTrigger: Der Build wurde durch einen Ressourcenauslöser ausgelöst oder durch einen anderen Build ausgelöst. Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Verzweigungsrichtlinien.	Ja
Build.Repository.Clean	Der Wert, den Sie für "Bereinigen " in den Quell-Repositoryeinstellungen ausgewählt haben. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.LocalPath	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Wichtig: 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 der Auscheckschritt für das Selbst-Repository (primär) keinen benutzerdefinierten Auscheckpfad definiert hat, oder der Auscheckpfad der Standardpfad $(Pipeline.Workspace)/s/<RepoName> für das Self-Repository ist, wird der Wert dieser Variable auf den Standardwert zurückgesetzt.$(Pipeline.Workspace)/s Wenn der Auscheckschritt für das Selbst-Repository (primär) einen benutzerdefinierten Auscheckpfad definiert hat (und nicht der Standardpfad mit mehreren Auscheckvorgängen ist), enthält diese Variable den genauen Pfad zum Self-Repository. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.ID	Der eindeutige Bezeichner des Repositorys. Dies ändert sich nicht, auch wenn der Name des Repositorys erfolgt. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
Build.Repository.Name	Der Name des auslösenden Repositorys. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Build.Repository.Provider	Der Typ des Trigger-Repositorys. TfsGit: TFS Git-Repository TfsVersionControl: Team Foundation-Versionskontrolle Git: Git-Repository, das auf einem externen Server gehostet wird GitHub Svn: Subversion Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Build.Repository.Tfvc.Workspace	Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Der Name des TFVC-Arbeitsbereichs , der vom Build-Agent verwendet wird. Wenn beispielsweise das Agent.BuildDirectory und c:\agent_work\12 das Agent.Id ist 8, könnte der Arbeitsbereichsname sein: ws_12_8 Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Build.Repository.Uri	Die URL für das Trigger-Repository. Beispiel: Git: https://dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Build.RequestedFor	Siehe "Wie werden die Identitätsvariablen festgelegt?". Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.	Ja
Build.RequestedForEmail	Siehe "Wie werden die Identitätsvariablen festgelegt?".	Ja
Build.RequestedForId	Siehe "Wie werden die Identitätsvariablen festgelegt?".	Ja
Build.SourceBranch	Der Zweig des auslösenden Repo, für den der Build in die Warteschlange gestellt wurde. Einige Beispiele: Git-Repo-Zweig: refs/heads/master Git-Repo-Pull-Anforderung: refs/pull/1/merge TFVC-Repo-Zweig: $/teamproject/main TFVC repo gated Check-In: Gated_2016-06-06_05.20.51.4369;username@live.com TFVC-Repo-Regale erstellen: myshelveset;username@live.com Wenn Ihre Pipeline durch ein Tag ausgelöst wird: refs/tags/your-tag-name Wenn Sie diese Variable im Buildnummerformat verwenden, werden die Schrägstrichzeichen (/) durch Unterstriche _ersetzt). Hinweis: In TFVC können Sie diese Variable nicht in Ihrem Buildformat verwenden, wenn Sie einen Gitter-Check-In-Build oder manuell erstellen.	Ja
Build.SourceBranchName	Der Name der Verzweigung im auslösenden Repo, für den der Build in die Warteschlange gestellt wurde. Git repo branch or pull request: The last path segment in the ref. In diesem Wert ist masterz. Brefs/heads/master. . In refs/heads/feature/tools diesem Wert ist tools. TFVC-Repo-Verzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert ist mainz. B$/teamproject/main. . TFVC-Repo-Eincheck- oder Regalset-Build ist der Name der Regale. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com. Hinweis: In TFVC können Sie diese Variable nicht in Ihrem Buildformat verwenden, wenn Sie einen Gitter-Check-In-Build oder manuell erstellen.	Ja
Build.SourcesDirectory	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Wichtig hinweis: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code. Wenn Sie mehrere Repositorys auschecken, wird sie auf den Standardwert zurückgesetzt, der $(Pipeline.Workspace)/sauch dann angezeigt wird, wenn das Selbst-Repository (primär) auf einen benutzerdefinierten Pfad ausgecheckt wird, der sich von seinem Standardpfad $(Pipeline.Workspace)/s/<RepoName> mit mehreren Auscheckvorgängen unterscheidet (in diesem Zusammenhang unterscheidet sich die Variable von dem Verhalten der Build.Repository.LocalPath-Variable). Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Build.SourceVersion	Die neueste Versionssteuerungsänderung des auslösenden Repo, das in diesem Build enthalten ist. Git: Die Commit-ID . TFVC: Das Changeset. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Ja
Build.SourceVersionMessage	Der Kommentar des Commit- oder Änderungssets für das auslösende Repo. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen ab, was immer kürzer ist. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag. Darüber hinaus ist diese Variable nur auf Schrittebene verfügbar und ist weder in der Auftrags- noch auf Phasenebene verfügbar (d. h. die Nachricht wird erst extrahiert, wenn der Auftrag gestartet und der Code ausgecheckt wurde). Hinweis: Diese Variable ist in TFS 2015.4 verfügbar.	Nein
Build.StagingDirectory	Der lokale Pfad auf dem Agent, in dem alle Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen" zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, damit Sie es nicht selbst bereinigen müssen. Siehe Artifacts in Azure Pipelines. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Build.Repository.Git.SubmoduleCheckout	Der Wert, den Sie für Untermodule auschecken auf der Registerkarte "Repository" ausgewählt haben. Mit mehreren ausgecheckten Repos verfolgt dieser Wert die Einstellung des Auslösens des Repositorys. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Build.SourceTfvcShelveset	Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Wenn Sie einen Gitterbau oder ein Regalet-Build ausführen, wird dies auf den Namen der Regale festgelegt, die Sie erstellen. Hinweis: Diese Variable gibt einen Wert zurück, der für die Verwendung in einem Buildnummerformat 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 Build-Abschlussauslöser ausgelöst. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	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 Build-Abschlussauslöser ausgelöst. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	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 Build-Abschlussauslöser ausgelöst. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Build.TriggeredBy.BuildNumber	Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die Anzahl des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Build-Abschlussauslöser ausgelöst. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	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 Build-Abschlussauslöser ausgelöst. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein
Common.TestResultsDirectory	Der lokale Pfad auf dem Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Nein

Pipelinevariablen (DevOps Server 2020)

Variable	BESCHREIBUNG
Pipeline.Workspace	Arbeitsbereichverzeichnis 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 nur zu Auftragsausführungszeit aufgelöst.

Variable	BESCHREIBUNG
Environment.Name	Name der Umgebung, die im Bereitstellungsauftrag ausgerichtet ist, um die Bereitstellungsschritte auszuführen und den Bereitstellungsverlauf aufzuzeichnen. Beispiel: smarthotel-dev.
Environment.Id	ID der Umgebung, die im Bereitstellungsauftrag ausgerichtet ist. Beispiel: 10.
Environment.ResourceName	Name der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag ausgerichtet ist, um die Bereitstellungsschritte auszuführen und den Bereitstellungsverlauf aufzuzeichnen. So ist z. B bookings . ein Kubernetes-Namespace, der der Umgebung smarthotel-devals Ressource hinzugefügt wurde.
Environment.ResourceId	ID der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag zum Ausführen der Bereitstellungsschritte ausgerichtet ist. Beispiel: 4.

Systemvariablen (DevOps Server 2020)

Variable	BESCHREIBUNG	In Vorlagen verfügbar?
System.AccessToken	Verwenden Sie das OAuth-Token, um auf die REST-API zuzugreifen. Verwenden Sie System.AccessToken aus YAML-Skripts. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.	Ja
System.CollectionId	Die GUID der TFS-Auflistung oder Azure DevOps Organisation	Ja
System.CollectionUri	Eine Zeichenfolge Team Foundation Server Auflistungs-URI.	Ja
System.DefaultWorkingDirectory	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein
System.DefinitionId	Die ID der Buildpipeline.	Ja
System.HostType	Legen Sie fest build , ob die Pipeline ein Build ist. Für eine Version sind deployment die Werte für einen Bereitstellungsgruppenauftrag, gates während der Auswertung von Gates und release für andere (Agent- und Agentless)-Aufträge.	Ja
System.JobAttempt	Legen Sie auf 1 fest, wenn dieser Auftrag zum ersten Mal versucht wird, und erhöhen Sie jedes Mal, wenn der Auftrag erneut bearbeitet wird.	Nein
System.JobDisplayName	Der menschenlesbare Name, der einem Auftrag zugewiesen wird.	Nein
System.JobId	Ein eindeutiger Bezeichner für einen einzelnen Versuch eines einzelnen Auftrags. Der Wert ist eindeutig für die aktuelle Pipeline.	Nein
System.JobName	Der Name des Auftrags, der in der Regel zum Ausdruck von Abhängigkeiten und zum Zugriff auf Ausgabevariablen verwendet wird.	Nein
System.PhaseAttempt	Legen Sie zum ersten Mal fest, dass diese Phase versucht wird, und erhöhen Sie jedes Mal, wenn der Auftrag erneut ausgeführt wird. Hinweis: "Phase" ist ein meist redundantes Konzept, das die Entwurfszeit für einen Auftrag darstellt (während der Auftrag die Laufzeitversion einer Phase war). Wir haben hauptsächlich das Konzept der "Phase" aus Azure Pipelines entfernt. Matrix- und Multikonfigurationsaufträge sind der einzige Ort, an dem sich "Phase" immer noch von "Job" unterscheidet. Eine Phase kann mehrere Aufträge instanziieren, die sich nur in ihren Eingaben unterscheiden.	Nein
System.PhaseDisplayName	Der menschliche lesbare Name, der einer Phase zugewiesen wird.	Nein
System.PhaseName	Ein Zeichenfolgen-basierter Bezeichner für einen Auftrag, der in der Regel zum Ausdrucken von Abhängigkeiten und zum Zugriff auf Ausgabevariablen verwendet wird.	Nein
System.StageAttempt	Legen Sie auf 1 fest, wenn diese Phase zum ersten Mal versucht wird, und erhöht jedes Mal, wenn der Auftrag erneut ausgeführt wird.	Nein
System.StageDisplayName	Der menschlich lesbare Name, der einer Stufe zugewiesen wird.	Nein
System.StageName	Ein Zeichenfolgen-basierter Bezeichner für eine Stufe, die in der Regel zum Ausdrucken von Abhängigkeiten und zugriff auf Ausgabevariablen verwendet wird.	Ja
System.PullRequest.IsFork	Wenn die Pullanforderung von einer Freihandeingabe des Repositorys stammt, wird diese Variable auf Truefestgelegt. Andernfalls ist er auf False.	Ja
System.PullRequest.PullRequestId	Die ID der Pullanforderung, die diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist).	Nein
System.PullRequest.PullRequestNumber	Die Anzahl der Pullanforderung, die diesen Build verursacht hat. Diese Variable wird für Pullanforderungen aus GitHub ausgefüllt, die eine andere Pullanforderungs-ID und eine Pullanforderungsnummer aufweisen. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Verzweigungsrichtlinie betroffen ist.	Nein
System.PullRequest.SourceBranch	Die Verzweigung, die in einer Pullanforderung überprüft wird. Beispiel: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist). Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Verzweigungsrichtlinie betroffen ist.	Nein
System.PullRequest.SourceRepositoryURI	Die URL zum Repository, das die Pullanforderung enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject.	Nein
System.PullRequest.TargetBranch	Die Verzweigung, die das Ziel einer Pullanforderung ist. Beispiel: refs/heads/master Wenn sich Ihr Repository in Azure Repos befindet und master sich ihr Repository in GitHub befindet. Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Verzweigungsrichtlinie betroffen ist.	Nein
System.TeamFoundationCollectionUri	Der URI der Team Foundation-Auflistung. Beispiel: https://dev.azure.com/fabrikamfiber/ Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	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	Legen Sie fest True , ob das Skript von einer Buildaufgabe ausgeführt wird. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.	Nein

Agentvariablen (DevOps Server 2019)

Hinweis

Sie können Agentvariablen als Umgebungsvariablen in Ihren Skripts und als Parameter in Ihren Buildaufgaben verwenden. Sie können sie nicht verwenden, um die Buildnummer anzupassen oder eine Versionssteuerungsbezeichnung oder ein Tag anzuwenden.

Variable	BESCHREIBUNG
Agent.BuildDirectory	Der lokale Pfad für den 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. Dies enthält die Agentsoftware. Beispiel: c:\agent.
Agent.Id	Die ID der Momentaufnahme.
Agent.JobName	Der Name des ausgeführten Auftrags. Dies ist in der Regel "Auftrag" oder "__default", aber in Multi-Config-Szenarien ist die Konfiguration.
Agent.JobStatus	Der Status des Builds. Canceled Failed Succeeded SucceededWithIssues (teilweise erfolgreich) Die Umgebungsvariable sollte als AGENT_JOBSTATUS. Die ältere agent.jobstatus ist zur Abwärtskompatibilität verfügbar.
Agent.MachineName	Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name	Der Name des Agents, der mit dem Pool registriert ist. Wenn Sie einen selbst gehosteten Agent verwenden, wird dieser Name von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.
Agent.OS	Das Betriebssystem des Agenthosts. Gültige Werte sind: Windows_NT Darwin Linux Wenn Sie in einem Container ausgeführt werden, kann der Agenthost und der Container verschiedene Betriebssysteme ausführen.
Agent.OSArchitecture	Die Prozessorarchitektur des Betriebssystems des Agenthosts. 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 .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu halten, bevor sie veröffentlicht werden.
Agent.ToolsDirectory	Das Verzeichnis, das von Aufgaben wie Node Tool Installer und Python-Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis PATH hinzu, damit nachfolgende Buildschritte sie verwenden können. Erfahren Sie mehr über das Verwalten dieses Verzeichnisses auf einem selbst gehosteten Agent.
Agent.WorkFolder	Das Arbeitsverzeichnis für diesen Agent. Beispiel: c:\agent_work. Dieses Verzeichnis ist nicht garantiert, dass durch Pipelineaufgaben geschrieben werden kann (z. B. wenn ein Container zugeordnet wird)

Buildvariablen (DevOps Server 2019)

Variable	BESCHREIBUNG
Build.ArtifactStagingDirectory	Der lokale Pfad auf dem Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen " zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen. Siehe Artifacts in Azure Pipelines. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.BuildId	Die ID des Datensatzes für den abgeschlossenen Build.
Build.BuildNumber	Der Name des abgeschlossenen Builds. Sie können das Buildnummernformat angeben, das diesen Wert in den Pipelineoptionen generiert. Eine typische Verwendung dieser Variablen besteht darin, es teil des Bezeichnungsformats zu machen, das Sie auf der Repositoryregisterkarte angeben. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.BuildUri	Der URI für den Build. Beispiel: vstfs:///Build/Build/1430. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.BinariesDirectory	Der lokale Pfad für den Agent, den Sie als Ausgabeordner für kompilierte Binärdateien verwenden können. Standardmäßig sind neue Buildpipelinen nicht zum Bereinigen dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um sie auf der Registerkarte "Repository" zu bereinigen. Beispiel: c:\agent_work\1\b. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.DefinitionName	Der Name der Buildpipeline. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.
Build.DefinitionVersion	Die Version der Buildpipeline.
Build.QueuedBy	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.
Build.QueuedById	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.
Build.Reason	Das Ereignis, das dazu führte, dass der Build ausgeführt wurde. Manual: Ein Benutzer hat den Build manuell in die Warteschlange gestellt. IndividualCI: Kontinuierliche Integration (CI), die von einem Git-Push oder einem TFVC-Check-In ausgelöst wird. BatchedCI: Kontinuierliche Integration (CI), die von einem Git-Push oder einer TFVC-Überprüfung ausgelöst wird, und die Batchänderungen wurden ausgewählt. Schedule: Geplanter Trigger. ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Regales manuell in die Warteschlange gestellt. CheckInShelveset: Gated Check-In-Trigger . PullRequest: Der Build wurde von einer Git-Verzweigungsrichtlinie ausgelöst, die einen Build erfordert. BuildCompletion: Der Build wurde von einem anderen Build ausgelöst. Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Verzweigungsrichtlinien.
Build.Repository.Clean	Der Wert, den Sie für "Bereinigen " in den Quell-Repositoryeinstellungen ausgewählt haben. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.LocalPath	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Diese Variable ist synonym für Build.SourcesDirectory.
Build.Repository.Name	Der Name des Repositorys. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Provider	Der Typ des ausgewählten Repositorys. TfsGit: TFS Git Repository TfsVersionControl: Team Foundation-Versionskontrolle Git: Git-Repository, das auf einem externen Server gehostet wird GitHub Svn: Subversion Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Tfvc.Workspace	Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Der Name des TFVC-Arbeitsbereichs , der vom Build-Agent verwendet wird. Wenn z. B. "Agent.BuildDirectory c:\agent_work\12 " und "Agent.Id" lautet 8, könnte der Arbeitsbereichsname folgendes sein: ws_12_8 Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Uri	Die URL für das Repository. Beispiel: Git: https://dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.RequestedFor	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.
Build.RequestedForEmail	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.
Build.RequestedForId	Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.
Build.SourceBranch	Der Zweig, für den der Build in die Warteschlange gestellt wurde. Einige Beispiele: Git-Repo-Verzweigung: refs/heads/master Git-Repo-Pullanforderung: refs/pull/1/merge TFVC-Repo-Verzweigung: $/teamproject/main TFVC-Repo-Check-In: Gated_2016-06-06_05.20.51.4369;username@live.com TFVC-Repo-Regale erstellen: myshelveset;username@live.com Wenn Sie diese Variable im Buildnummernformat verwenden, werden die Schrägstrichzeichen (/) durch Unterstriche _ersetzt). Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.
Build.SourceBranchName	Der Name der Verzweigung, für die der Build in die Warteschlange gestellt wurde. Git repo branch or pull request: The last path segment in the ref. In diesem Wert ist masterz. Brefs/heads/master. . In refs/heads/feature/tools diesem Wert ist tools. TFVC-Repo-Verzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. Beispiel für $/teamproject/main diesen Wert ist main. TFVC Repo gated Check-In oder Regalet Build ist der Name des Regals. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com. Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.
Build.SourcesDirectory	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Diese Variable ist synonym für Build.Repository.LocalPath.
Build.SourceVersion	Die neueste Versionssteuerelementänderung, die in diesem Build enthalten ist. Git: Die Commit-ID . TFVC: das Changeset. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.SourceVersionMessage	Der Kommentar des Commit- oder Änderungssets. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen, je nachdem, was kürzer ist. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Hinweis: Diese Variable ist in TFS 2015.4 verfügbar.
Build.StagingDirectory	Der lokale Pfad auf dem Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen " zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen. Siehe Artifacts in Azure Pipelines. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Git.SubmoduleCheckout	Der Wert, den Sie für Untermodule auschecken auf der Registerkarte "Repository" ausgewählt haben. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.SourceTfvcShelveset	Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Wenn Sie einen gated Build oder einen Regalet-Build ausführen, wird dies auf den Namen der Regale festgelegt, die Sie erstellen. Hinweis: Diese Variable gibt einen Wert zurück, der für die Buildverwendung in einem Buildnummernformat ungültig ist.
Build.TriggeredBy.BuildId	Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die BuildID des auslösenden Builds festgelegt. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.TriggeredBy.DefinitionId	Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.TriggeredBy.DefinitionName	Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.TriggeredBy.BuildNumber	Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die Anzahl des auslösenden Builds festgelegt. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.TriggeredBy.ProjectID	Wenn der Build von einem 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-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Common.TestResultsDirectory	Der lokale Pfad für den Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Systemvariablen (DevOps Server 2019)

Variable	BESCHREIBUNG
System.AccessToken	Verwenden Sie das OAuth-Token, um auf die REST-API zuzugreifen. Verwenden Sie System.AccessToken aus YAML-Skripts. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
System.CollectionId	Die GUID der TFS-Auflistung oder Azure DevOps Organisation
System.DefaultWorkingDirectory	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
System.DefinitionId	Die ID der Buildpipeline.
System.HostType	Legen Sie fest build , ob die Pipeline ein Build ist. Für eine Version gelten deployment die Werte für einen Bereitstellungsgruppenauftrag und release für einen Agent-Auftrag.
System.PullRequest.IsFork	Wenn die Pullanforderung von einer Freihandeingabe des Repositorys stammt, wird diese Variable auf Truefestgelegt. Andernfalls ist er auf False.
System.PullRequest.PullRequestId	Die ID der Pullanforderung, die diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist.)
System.PullRequest.PullRequestNumber	Die Anzahl der Pullanforderung, die diesen Build verursacht hat. Diese Variable wird für Pullanforderungen aus GitHub ausgefüllt, die eine andere Pullanforderungs-ID und eine Pullanforderungsnummer aufweisen.
System.PullRequest.SourceBranch	Die Verzweigung, die in einer Pullanforderung überprüft wird. Beispiel: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist.)
System.PullRequest.SourceRepositoryURI	Die URL zum Repository, das die Pullanforderung enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Azure Repos Git PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist. Es wird nicht für GitHub PRs initialisiert.)
System.PullRequest.TargetBranch	Die Verzweigung, die das Ziel einer Pullanforderung ist. Beispiel: refs/heads/master. Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist.
System.TeamFoundationCollectionUri	Der URI der Team Foundation-Auflistung. Beispiel: https://dev.azure.com/fabrikamfiber/. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
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	Legen Sie fest True , ob das Skript von einer Buildaufgabe ausgeführt wird. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Agentvariablen (TFS 2018)

Hinweis

Sie können Agentvariablen als Umgebungsvariablen in Ihren Skripts und als Parameter in Ihren Buildaufgaben verwenden. Sie können sie nicht verwenden, um die Buildnummer anzupassen oder eine Versionssteuerungsbezeichnung oder ein Tag anzuwenden.

Variable	BESCHREIBUNG
Agent.BuildDirectory	Der lokale Pfad für den 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. Dies enthält die Agentsoftware. Beispiel: c:\agent.
Agent.Id	Die ID der Momentaufnahme.
Agent.JobStatus	Der Status des Builds. Canceled Failed Succeeded SucceededWithIssues (teilweise erfolgreich) Die Umgebungsvariable sollte als AGENT_JOBSTATUS. Die ältere agent.jobstatus ist zur Abwärtskompatibilität verfügbar.
Agent.MachineName	Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name	Der Name des Agents, der mit dem Pool registriert ist. Dieser Name wird von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.
Agent.TempDirectory	Ein temporärer Ordner, der nach jedem Pipelineauftrag bereinigt wird. Dieses Verzeichnis wird von Aufgaben wie .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu halten, bevor sie veröffentlicht werden.
Agent.ToolsDirectory	Das Verzeichnis, das von Aufgaben wie Node Tool Installer und Python-Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis PATH hinzu, damit nachfolgende Buildschritte sie verwenden können. Erfahren Sie mehr über das Verwalten dieses Verzeichnisses auf einem selbst gehosteten Agent.
Agent.WorkFolder	Das Arbeitsverzeichnis für diesen Agent. Beispiel: c:\agent_work.

Buildvariablen (TFS 2018)

Variable	BESCHREIBUNG
Build.ArtifactStagingDirectory	Der lokale Pfad auf dem Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Der lokale Pfad auf dem Agent, in den alle Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen " zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen. Siehe Artifacts in Azure Pipelines. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.BuildId	Die ID des Datensatzes für den abgeschlossenen Build.
Build.BuildNumber	Der Name des abgeschlossenen Builds. Sie können das Buildnummerformat angeben, das diesen Wert in den Pipelineoptionen generiert. Eine typische Verwendung dieser Variable besteht darin, ihn zum 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 schlägt das Bezeichnungsformat fehl. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Versionssteuerungstag.
Build.BuildUri	Der URI für den Build. Beispiel: vstfs:///Build/Build/1430. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.BinariesDirectory	Der lokale Pfad im Agent, den Sie als Ausgabeordner für kompilierte Binärdateien verwenden können. Standardmäßig sind neue Buildpipelinen nicht eingerichtet, um dieses Verzeichnis zu bereinigen. Sie können Ihren Build definieren, um sie auf der Registerkarte "Repository" zu bereinigen. Beispiel: c:\agent_work\1\b. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.DefinitionName	Der Name der Buildpipeline. Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.
Build.DefinitionVersion	Die Version der Buildpipeline.
Build.QueuedBy	Siehe "Wie werden die Identitätsvariablen festgelegt?". Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.
Build.QueuedById	Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.Grund	Das Ereignis, das dazu führte, dass der Build ausgeführt wird. Manual: Ein Benutzer hat den Build manuell aus der Benutzeroberfläche oder einen API-Aufruf in die Warteschlange gestellt. IndividualCI: Kontinuierliche Integration (CI) ausgelöst durch einen Git-Push oder ein TFVC-Check-In. BatchedCI: Fortlaufende Integration (CI) ausgelöst durch einen Git-Push oder ein TFVC-Check-In, und die Batchänderungen wurden ausgewählt. Schedule: Geplanter Trigger. ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Regalets manuell in die Warteschlange gestellt. CheckInShelveset: Check-In-Trigger für Gitter . PullRequest: Der Build wurde durch eine Git-Verzweigungsrichtlinie ausgelöst, die einen Build erfordert. Siehe Buildpipeline-Trigger, Verbessern der Codequalität mit Zweigrichtlinien.
Build.Repository.Clean	Der Wert, den Sie für "Bereinigen" in den Quell-Repositoryeinstellungen ausgewählt haben. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.LocalPath	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Diese Variable ist synonym mit Build.SourcesDirectory.
Build.Repository.Name	Der Name des Repositorys. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Provider	Der Typ des von Ihnen ausgewählten Repositorys. TfsGit: TFS Git-Repository TfsVersionControl: Team Foundation-Versionskontrolle Git: Git-Repository, das auf einem externen Server gehostet wird Svn: Subversion Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Tfvc.Workspace	Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Der Name des TFVC-Arbeitsbereichs , der vom Build-Agent verwendet wird. Wenn beispielsweise das Agent.BuildDirectory und c:\agent_work\12 das Agent.Id ist 8, könnte der Arbeitsbereichsname sein: ws_12_8 Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Uri	Die URL für das Repository. Beispiel: Git: https://fabrikamfiber/tfs/DefaultCollection/Scripts/_git/Scripts TFVC: https://fabrikamfiber/tfs/DefaultCollection/ Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.RequestedFor	Siehe "Wie werden die Identitätsvariablen festgelegt?". Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.
Build.RequestedForEmail	Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.RequestedForId	Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.SourceBranch	Der Zweig, für den der Build in die Warteschlange gestellt wurde. Einige Beispiele: Git-Repo-Zweig: refs/heads/master Git-Repo-Pull-Anforderung: refs/pull/1/merge TFVC-Repo-Zweig: $/teamproject/main TFVC repo gated Check-In: Gated_2016-06-06_05.20.51.4369;username@live.com TFVC-Repo-Regale erstellen: myshelveset;username@live.com Wenn Sie diese Variable im Buildnummerformat verwenden, werden die Schrägstrichzeichen (/) durch Unterstriche _ersetzt). Hinweis: In TFVC können Sie diese Variable nicht in Ihrem Buildformat verwenden, wenn Sie einen Gitter-Check-In-Build oder manuell erstellen.
Build.SourceBranchName	Der Name des Zweigs, für den der Build in die Warteschlange gestellt wurde. Git repo branch or pull request: The last path segment in the ref. In diesem Wert ist masterz. Brefs/heads/master. . In refs/heads/feature/tools diesem Wert ist tools. TFVC-Repo-Verzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert ist mainz. B$/teamproject/main. . TFVC-Repo-Eincheck- oder Regalset-Build ist der Name der Regale. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com. Hinweis: In TFVC können Sie diese Variable nicht in Ihrem Buildformat verwenden, wenn Sie einen Gitter-Check-In-Build oder manuell erstellen.
Build.SourcesDirectory	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Diese Variable ist synonym mit Build.Repository.LocalPath.
Build.SourceVersion	Die neueste Versionssteuerungsänderung, die in diesem Build enthalten ist. Git: Die Commit-ID . TFVC: Das Changeset. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.SourceVersionMessage	Der Kommentar des Commit- oder Änderungssets. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen ab, was immer kürzer ist. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag. Hinweis: Diese Variable ist in TFS 2015.4 verfügbar.
Build.StagingDirectory	Der lokale Pfad auf dem Agent, in dem alle Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen" zu veröffentlichen. Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, damit Sie es nicht selbst bereinigen müssen. Siehe Artifacts in Azure Pipelines. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Git.SubmoduleCheckout	Der Wert, den Sie für Untermodule auschecken auf der Registerkarte "Repository" ausgewählt haben. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.SourceTfvcShelveset	Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Wenn Sie einen Gitterbau oder ein Regalet-Build ausführen, wird dies auf den Namen der Regale festgelegt, die Sie erstellen. Hinweis: Diese Variable gibt einen Wert zurück, der für die Verwendung in einem Buildnummerformat ungültig ist.
Common.TestResultsDirectory	Der lokale Pfad auf dem Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Systemvariablen (TFS 2018)

Variable	BESCHREIBUNG
System.AccessToken	Verwenden Sie das OAuth-Token, um auf die REST-API zuzugreifen. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
System.CollectionId	Die GUID der TFS-Auflistung oder Azure DevOps Organisation
System.DefaultWorkingDirectory	Der lokale Pfad auf dem Agent, in dem Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s Standardmäßig aktualisieren neue Buildpipelinen nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte "Repository" heruntergeladen werden. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
System.DefinitionId	Die ID der Buildpipeline.
System.HostType	build Legen Sie fest, ob die Pipeline ein Build ist oder release wenn die Pipeline eine Version ist.
System.PullRequest.IsFork	Wenn die Pullanforderung von einer Freihand des Repositorys stammt, wird diese Variable auf True"festgelegt" festgelegt. Andernfalls ist er auf False". Verfügbar in TFS 2018.2.
System.PullRequest.PullRequestId	Die ID der Pullanforderung, die diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist.)
System.PullRequest.SourceBranch	Die Verzweigung, die in einer Pullanforderung überprüft wird. Beispiel: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist.)
System.PullRequest.SourceRepositoryURI	Die URL zum Repo, das die Pullanforderung enthält. Beispiel: http://our-server:8080/tfs/DefaultCollection/_git/OurProject. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Azure Repos Git PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist.)
System.PullRequest.TargetBranch	Der Zweig, der das Ziel einer Pullanforderung ist. Beispiel: refs/heads/master. Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist.
System.TeamFoundationCollectionUri	Der URI der Team foundation-Auflistung. Beispiel: http://our-server:8080/tfs/DefaultCollection/. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
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	True Legen Sie fest, ob das Skript von einer Buildaufgabe ausgeführt wird. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Wie werden die Identitätsvariablen festgelegt?

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

Wenn der Build ausgelöst wird...	Dann basieren die Werte Build.QueuedBy und Build.QueuedById auf...	Dann basieren die Werte Build.RequestedFor und Build.RequestedForId auf...
In Git oder TFVC durch die Continuous Integration (CI) Trigger	Die Systemidentität, z. B.: [DefaultCollection]\Project Collection Service Accounts	Die Person, die die Änderungen verschoben oder eingecheckt hat.
In Git oder durch einen Verzweigungsrichtlinienbuild.	Die Systemidentität, z. B.: [DefaultCollection]\Project Collection Service Accounts	Die Person, die die Änderungen eingecheckt hat.
In TFVC durch einen eingetürmten 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
Da Sie auf die Schaltfläche " Warteschlangenbuild " geklickt haben	Sie	Sie