Verwenden vordefinierter Variablen

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 Bezeichnung oder ein Tag der Versionskontrolle anzuwenden.

VariableBeschreibung
Agent.BuildDirectory

Der lokale Pfad auf dem Agent, in dem alle Ordner für eine bestimmte Buildpipeline erstellt werden. Diese Variable hat den gleichen 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 dem der Agent installiert ist. Dieser enthält die Agent-Software. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobName Der Name des ausgeführten Auftrags. Dies ist normalerweise "Job" oder "__default", aber in Szenarien mit mehreren Konfigurationen ist die Konfiguration.
Agent.JobStatus Der Status des Build.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Auf die Umgebungsvariable sollte als verwiesen AGENT_JOBSTATUS werden. Die ältere agent.jobstatus ist aus Gründen der Abwärtskompatibilität verfügbar.

Agent.MachineName Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name

Der Name des Agents, der beim Pool registriert ist.

Wenn Sie einen selbstge 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 ausführen, werden auf dem Agenthost und dem Container möglicherweise andere Betriebssysteme ausgeführt.
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 Tasks wie z. B. .NET Core-CLI verwendet, um temporäre Elemente wie Testergebnisse vor der Veröffentlichung zu enthalten.

Beispiel: /home/vsts/work/_temp für Ubuntu

Agent.ToolsDirectory Das Verzeichnis, das von Aufgaben wie dem Node Tool-Installer und der Python-Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis hinzu, PATH damit sie von nachfolgenden Buildschritten verwendet werden können.

Erfahren Sie mehr über die Verwaltung dieses Verzeichnisses auf einem selbstge gehosteten Agent.
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work.

Hinweis: Es ist nicht garantiert, dass dieses Verzeichnis von Pipelineaufgaben (z. B. bei Zuordnung zu einem Container)

Buildvariablen (DevOps Services)


VariableBeschreibungIn Vorlagen verfügbar?
Build.ArtifactStagingDirectory

Der lokale Pfad auf dem Agent, in den Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit zur Verwendung dieses Ordners besteht in der Veröffentlichung Ihrer Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte 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 im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
Build.BuildId Die ID des Datensatzes für den abgeschlossenen Build. Nein
Build.BuildNumber Der Name des abgeschlossenen Build, auch als Ausführungsnummer bezeichnet. Sie können angeben, was in diesem Wert enthalten ist.

Diese Variable wird normalerweise verwendet, um sie in das Bezeichnungsformat zu ändern, das Sie auf der Registerkarte Repository angeben.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen kann das Bezeichnungsformat nicht verwendet werden.



Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
Build.BuildUri Der URI für den Build. Ein Beispiel für die Camel-Case-Schreibweise lautet: vstfs:///Build/Build/1430.

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

Standardmäßig sind keine neuen Buildpipelines für die Bereinigung dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um ihn auf der Registerkarte Repository zu bereinigt.

Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work\1\b.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.ContainerId Die ID des Containers für Ihr Artefakt. Wenn Sie ein Artefakt in Ihre Pipeline hochladen, wird es einem Container hinzugefügt, der 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 kann das Bezeichnungsformat nicht verwendet werden.

Ja
Build.DefinitionVersion Die Version der Buildpipeline. Ja
Build.QueuedBy Siehe "Wie werden die Identitätsvariablen festgelegt?".

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen kann das Bezeichnungsformat nicht verwendet werden.

Ja
Build.QueuedById Siehe "Wie werden die Identitätsvariablen festgelegt?". Ja
Build.Reason Das Ereignis, das die Ausführung des Build verursacht hat.
  • Manual: Ein Benutzer hat den Build manuell in die Warteschlange gestellt.
  • IndividualCI: IndividualCI die durch einen Git-Push oder ein TFVC-Einchecken ausgelöst wird.
  • BatchedCI: BatchedCI ausgelöst durch einen Git-Push oder ein TFVC-Einchecken, und die Batch-Änderungen wurden ausgewählt.
  • Schedule: Schedule Trigger.
  • ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Shelvesets manuell in die Warteschlange gestellt.
  • CheckInShelveset: CheckInShelveset
  • PullRequest: Der Build wurde durch eine Git-Branchrichtlinie ausgelöst, die einen Build erfordert.
  • ResourceTrigger: Der Build wurde ResourceTrigger durch einen anderen Build ausgelöst.
Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Branchrichtlinien.
Ja
Build.Repository.Clean Der Wert, den Sie in den Einstellungen des Quellrepositorys für Bereinigt ausgewählt haben.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.Repository.LocalPath

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

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

Wichtiger Hinweis: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code. Wenn Sie mehrere Repositorys auschecken, ist das Verhalten wie folgt (und kann sich vom Wert der Variablen Build.SourcesDirectory unterscheiden):

  • Wenn für den Auscheckschritt für das Repository selbst (primär) kein benutzerdefinierter Auscheckpfad definiert ist oder der Auscheckpfad der Standardpfad für das Self-Checkout-Repository ist, wird der Wert dieser Variablen auf den Standardwert zurückverwendet, d. h. $(Pipeline.Workspace)/s/<RepoName>$(Pipeline.Workspace)/s .
  • Wenn für den Auscheckschritt für das Repository selbst (primär) ein benutzerdefinierter Auscheckpfad definiert ist (und es sich nicht um den Standardpfad mit mehreren Auschecken) ist, enthält diese Variable den genauen Pfad zum Selbstrepository.
Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.Repository.ID Der eindeutige Bezeichner des Repositorys.

Dies ändert sich auch dann nicht, wenn der Name des Repositorys dies tut.

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

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.Repository.Provider Der Typ des auslösenden Repositorys.
  • TfsGit: TfsGit
  • TfsVersionControl: TfsVersionControl
  • Git: Git-Repository, das auf einem externen Server gehostet wird
  • GitHub
  • Svn: Subversion
Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.Repository.Tfvc.Workspace Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird.


Wenn z. B. Agent.BuildDirectory und der Agent.Id ist, kann der c:\agent_work\128 Arbeitsbereichsname wie der folgende sein: ws_12_8

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

Ja
Build.RequestedForEmail Siehe "Wie werden die Identitätsvariablen festgelegt?". Ja
Build.RequestedForId Siehe "Wie werden die Identitätsvariablen festgelegt?". Ja
Build.SourceBranch Der Branch des auslösenden Repositorys, für das der Build in die Warteschlange gestellt wurde. Einige Beispiele:
  • Git-Repository-Branch: refs/heads/master
  • Git-Repository-Pull Request: refs/pull/1/merge
  • TFVC-Repository-Branch: $/teamproject/main
  • Einchecken des TFVC-Repositorys: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC-Repository-Shelveset-Build: 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ägstriche ( / ) durch Unterstriche _ ersetzt.

Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheck-Build ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummerformat verwenden.
Ja
Build.SourceBranchName Der Name des Branchs im auslösenden Repository, für das der Build in die Warteschlange gestellt wurde.
  • Git-Repositoryverzweigung oder Pull Request: Das letzte Pfadsegment im Verweis. In diesem Wert refs/heads/master ist beispielsweise master . In refs/heads/feature/tools diesem Wert ist tools .
  • TFVC-Repository-Branch: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert $/teamproject/main ist beispielsweise main .
  • Der TfVC-Repository-Gated Check-In- oder Shelveset-Build ist der Name des Shelvesets. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheckbuild ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummernformat verwenden.
Ja
Build.SourcesDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien.

Wichtiger Hinweis: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code. Wenn Sie mehrere Repositorys auschecken, wird auf den Standardwert zurückgesetzt, der $(Pipeline.Workspace)/s ist, auch wenn das selbst (primäre) Repository in einen benutzerdefinierten Pfad ausgecheckt wird, der sich vom Standardpfad mit mehreren Auschecken unterscheidet $(Pipeline.Workspace)/s/<RepoName> (in dieser Hinsicht unterscheidet sich die Variable vom Verhalten der Variablen Build.Repository.LocalPath).

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
Build.SourceVersion Die neueste Änderung der Versionskontrolle des auslösenden Repositorys, das in diesem Build enthalten ist. Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag. Ja
Build.SourceVersionMessage Der Kommentar des Commits oder Changesets für das auslösende Repository. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen, je nachdem, welcher Wert kürzer ist.

Entspricht Build.SourceVersionMessage der Nachricht beim Build.SourceVersion Commit. Der Build.SourceVersion Commit für einen PR-Build ist der Mergecommit (nicht der Commit im Quellverzweigung).

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag. Außerdem ist diese Variable nur auf Schrittebene verfügbar und weder auf Auftrags- noch auf Phasenebene verfügbar (d. h. die Nachricht wird erst extrahiert, nachdem der Auftrag gestartet und der Code ausgecheckt wurde).

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

Nein
Build.StagingDirectory

Der lokale Pfad auf dem Agent, in den artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit, diesen Ordner zu verwenden, besteht darin, Ihre Buildartefakte mit den Aufgaben Kopieren von Dateien und Veröffentlichen von Buildartefakten 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.

Weitere Informationen finden Sie unter Artifacts in Azure Pipelines.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
Build.Repository.Git.SubmoduleCheckout Der Wert, den Sie für die Untermodule "Auschecken" auf der Registerkarte "Repository"ausgewählt haben. Wenn mehrere Repositorys ausgecheckt sind, verfolgt dieser Wert die Einstellung des auslösenden Repositorys nach.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.SourceTfvcShelveset Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist.


Wenn Sie einen geschlossenen Build oder einen Shelvesetbuildausführen, wird dies auf den Namen des von Ihnen erstellten Shelvesets festgelegt.

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

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die resources verwenden.
Nein
Build.TriggeredBy.DefinitionId Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildabschlusstrigger ausgelöst.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die resources verwenden.
Nein
Build.TriggeredBy.DefinitionName Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildabschlusstrigger ausgelöst.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die resources verwenden.
Nein
Build.TriggeredBy.BuildNumber Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf die Nummer des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildabschlusstrigger ausgelöst.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

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

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Wenn Sie eine YAML-Pipeline mit resources auslösen, sollten Sie stattdessen die resources 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 im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein

Pipelinevariablen (DevOps Services)

VariableBeschreibung
Pipeline.Workspace Arbeitsbereichsverzeichnis für eine bestimmte Pipeline. Diese Variable hat den gleichen Wert wie Agent.BuildDirectory .

Beispiel: /home/vsts/work/1.

Bereitstellungsauftragsvariablen (DevOps Services)

Diese Variablen gelten für einen bestimmten Bereitstellungsauftrag und werden nur zur Auftragsausführungszeit aufgelöst.

VariableBeschreibung
Environment.Name Name der Umgebung, die im Bereitstellungsauftrag zum Ausführen der Bereitstellungsschritte und aufzeichnen des Bereitstellungsverlaufs als Ziel ist. Beispiel: smarthotel-dev.
Environment.Id ID der Umgebung, die im Bereitstellungsauftrag als Ziel ausgewählt ist. Beispiel: 10.
Environment.ResourceName Name der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag zum Ausführen der Bereitstellungsschritte und Aufzeichnen des Bereitstellungsverlaufs als Ziel ausgewählt ist. Dies ist beispielsweise bookings ein Kubernetes-Namespace, der der Umgebung als Ressource hinzugefügt smarthotel-dev wurde.
Environment.ResourceId ID der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag zum Ausführen der Bereitstellungsschritte als Ziel ausgewählt ist. Beispiel: 4.
Strategy.Name Der Name der Bereitstellungsstrategie: canaryrunOnce , oder rolling .
Strategy.CycleName Der aktuelle Zyklusname in einer Bereitstellung. Optionen sind PreIteration , Iteration oder PostIteration .

Systemvariablen (DevOps Services)

VariableBeschreibungVerfügbar in Vorlagen?
System.AccessToken Verwenden Sie das OAuth-Token, um auf die REST-API zuzugreifen.

Verwenden Sie System.AccessToken aus YAML-Skripts.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Ja
System.CollectionId Die GUID der TFS-Sammlung oder Azure DevOps Organisation. Ja
System.CollectionUri Der URI der TFS-Sammlung oder Azure DevOps Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/. Ja
System.DefaultWorkingDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
System.DefinitionId Die ID der Buildpipeline. Ja
System.HostType Legen Sie auf fest, wenn es sich build bei der Pipeline um einen Build handelt. Für ein Release gelten die Werte deployment für einen Bereitstellungsgruppenauftrag, gates während der Auswertung von Gates und für andere Aufträge release (Ohne Agent und Agent). Ja
System.JobAttempt Legen Sie beim ersten Versuch dieses Auftrags auf 1 fest, und wird jedes Mal inkrementiert, wenn der Auftrag wiederholt wird. Nein
System.JobDisplayName Der lesbare Name, der einem Auftrag gegeben wird. Nein
System.JobId Ein eindeutiger Bezeichner für einen einzelnen Versuch eines einzelnen Auftrags. Der Wert ist für die aktuelle Pipeline eindeutig. Nein
System.JobName Der Name des Auftrags, der normalerweise zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet wird. Nein
System.PhaseAttempt Legen Sie beim ersten Versuch dieser Phase auf 1 fest, und wird jedes Mal inkrementiert, wenn der Auftrag wiederholt wird.

Hinweis: "Phase" ist ein größtenteils redundantes Konzept, das die Entwurfszeit für einen Auftrag darstellt (während der Auftrag die Laufzeitversion einer Phase war). Wir haben das Konzept der "Phase" größtenteils aus Azure Pipelines entfernt. Matrixaufträge und Aufträge mit mehreren Konfigurationen sind der einzige Ort, an dem sich "phase" noch von "job" unterscheidet. Eine Phase kann mehrere Aufträge instanziieren, die sich nur in ihren Eingaben unterscheiden.
Nein
System.PhaseDisplayName Der lesbare Name, der einer Phase gegeben wird. Nein
System.PhaseName Ein zeichenfolgenbasierter Bezeichner für einen Auftrag, der in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet wird. Nein
System.StageAttempt Legen Sie beim ersten Versuch dieser Phase auf 1 fest, und wird jedes Mal inkrementiert, wenn der Auftrag wiederholt wird. Nein
System.StageDisplayName Der lesbare Name, der einer Phase gegeben wird. Nein
System.StageName Ein zeichenfolgenbasierter Bezeichner für eine Phase, der in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet wird. Ja
System.PullRequest.IsFork Wenn der Pull Request von einem Fork des Repositorys stammt, wird diese Variable auf True festgelegt. Andernfalls wird sie auf False festgelegt. Ja
System.PullRequest.PullRequestId Die ID des Pull Requests, der diesen Build verursacht hat. Ein Beispiel für die Camel-Case-Schreibweise lautet: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PRausgeführt wurde, der von einer Branchrichtlinie betroffen ist. Nein
System.PullRequest.PullRequestNumber Die Nummer des Pull Requests, der diesen Build verursacht hat. Diese Variable wird für Pull Requests von GitHub mit einer anderen Pull Request-ID und Pull Request-Nummer aufgefüllt. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn der PR von einer Branchrichtlinie betroffen ist. Nein
System.PullRequest.SourceBranch Der Branch, der in einem Pull Request überprüft wird. Beispiel: refs/heads/users/raisa/new-feature für Azure Repos. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PRausgeführt wurde, der von einer Branchrichtlinie betroffen ist. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn der PR von einer Branchrichtlinie betroffen ist. Nein
System.PullRequest.SourceRepositoryURI Die URL zum Repository, das den Pull Request enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject. Nein
System.PullRequest.TargetBranch Der Branch, der das Ziel eines Pull Requests ist. Beispiel: refs/heads/master Ihr Repository befindet sich in Azure Repos und master ihr Repository befindet sich in GitHub. Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR, der von einer Branchrichtlinie betroffen ist, wurde. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn der PR von einer Branchrichtlinie betroffen ist. Nein
System.TeamFoundationCollectionUri Der URI der TFS-Sammlung oder Azure DevOps Organisation. Ein Beispiel für die Camel-Case-Schreibweise lautet: https://dev.azure.com/fabrikamfiber/.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 Wird auf True festgelegt, wenn das Skript von einer Buildaufgabe ausgeführt wird.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein

Überprüft Variablen (DevOps Services)

VariableBeschreibung
Checks.StageAttempt Legen Sie beim ersten Versuch dieser Phase auf 1 fest, und wird jedes Mal erhöht, wenn die Phase wiederholt wird.

Diese Variable kann nur innerhalb einer Genehmigung oder Überprüfung auf eine Umgebung verwendet werden. Beispielsweise können Sie in einer Invoke $(Checks.StageAttempt)$(Checks.StageAttempt)

Add the stage attempt as a parameter.

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 Bezeichnung oder ein Tag der Versionskontrolle anzuwenden.

VariableBeschreibung
Agent.BuildDirectory

Der lokale Pfad auf dem Agent, in dem alle Ordner für eine bestimmte Buildpipeline erstellt werden. Diese Variable hat den gleichen Wert wie Pipeline.Workspace .

Beispiel: /home/vsts/work/1

Agent.HomeDirectory Das Verzeichnis, in dem der Agent installiert ist. Dieser enthält die Agent-Software. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobName Der Name des ausgeführten Auftrags. Dies ist normalerweise "Job" oder "__default", aber in Szenarien mit mehreren Konfigurationen ist die Konfiguration.
Agent.JobStatus Der Status des Build.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Auf die Umgebungsvariable sollte als verwiesen AGENT_JOBSTATUS werden. Die ältere agent.jobstatus ist aus Gründen der Abwärtskompatibilität verfügbar.

Agent.MachineName Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name

Der Name des Agents, der beim Pool registriert ist.

Wenn Sie einen selbstge 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 ausführen, werden auf dem Agenthost und dem Container möglicherweise andere Betriebssysteme ausgeführt.
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 Tasks wie z. B. .NET Core-CLI verwendet, um temporäre Elemente wie Testergebnisse vor der Veröffentlichung zu enthalten.

Beispiel: /home/vsts/work/_temp für Ubuntu

Agent.ToolsDirectory Das Verzeichnis, das von Aufgaben wie dem Node Tool-Installer und der Python-Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis hinzu, PATH damit sie von nachfolgenden Buildschritten verwendet werden können.

Erfahren Sie mehr über die Verwaltung dieses Verzeichnisses auf einem selbstge gehosteten Agent.
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work.

Hinweis: Es ist nicht garantiert, dass dieses Verzeichnis von Pipelineaufgaben (z. B. bei Zuordnung zu einem Container)

Buildvariablen (DevOps Server 2020)


VariableBeschreibungIn Vorlagen verfügbar?
Build.ArtifactStagingDirectory

Der lokale Pfad auf dem Agent, in den Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit zur Verwendung dieses Ordners besteht in der Veröffentlichung Ihrer Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte 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 im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
Build.BuildId Die ID des Datensatzes für den abgeschlossenen Build. Nein
Build.BuildNumber Der Name des abgeschlossenen Build, auch als Ausführungsnummer bezeichnet. Sie können angeben, was in diesem Wert enthalten ist.

Eine typische Verwendung dieser Variablen besteht darin, sie in das Bezeichnungsformat zu machen, das Sie auf der Registerkarte Repositoryangeben.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.



Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
Build.BuildUri Der URI für den Build. Ein Beispiel für die Camel-Case-Schreibweise lautet: vstfs:///Build/Build/1430.

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

Standardmäßig sind keine neuen Buildpipelines zum Bereinigen dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um ihn auf der Registerkarte Repositoryzu bereinigen.

Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work\1\b.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.ContainerId Die ID des Containers für Ihr Artefakt. Wenn Sie ein Artefakt in Ihre Pipeline hochladen, wird es einem Container hinzugefügt, der 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?".

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?". Ja
Build.Reason Das Ereignis, das die Ausführung des Builds verursacht hat.
  • Manual: Ein Benutzer hat den Build manuell in die Warteschlange eingereiht.
  • IndividualCI: IndividualCI ausgelöst durch einen Git-Push oder ein TFVC-Einchecken.
  • BatchedCI: BatchedCI die durch einen Git-Push oder ein TFVC-Einchecken ausgelöst wird, und die Batch-Änderungen wurden ausgewählt.
  • Schedule: Schedule Trigger.
  • ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Shelvesets manuell in die Warteschlange eingereiht.
  • CheckInShelveset: CheckInShelveset
  • PullRequest: Der Build wurde durch eine Git-Branchrichtlinie ausgelöst, die einen Build erfordert.
  • ResourceTrigger: Der Build wurde ResourceTrigger oder durch einen anderen Build ausgelöst.
Weitere Informationen finden Sie unter Erstellen von Pipelinetriggern, Verbessern der Codequalität mit Branchrichtlinien.
Ja
Build.Repository.Clean Der Wert, den Sie für Bereinigen in den Quell-Repositoryeinstellungenausgewählt haben.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.Repository.LocalPath

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Wichtiger Hinweis: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code. Wenn Sie mehrere Repositorys auschecken, sieht das Verhalten wie folgt aus (und unterscheidet sich möglicherweise vom Wert der Variablen Build.SourcesDirectory):

  • Wenn für den Auscheckschritt für das selbst (primäre) Repository kein benutzerdefinierter Auscheckpfad definiert ist oder der Auscheckpfad der Standardpfad für das Selbstrepository mit mehrfacher Auscheckung $(Pipeline.Workspace)/s/<RepoName> ist, wird der Wert dieser Variablen auf den Standardwert zurückgesetzt, der $(Pipeline.Workspace)/s ist.
  • Wenn für den Auscheckschritt für das selbst (primäre) Repository ein benutzerdefinierter Auscheckpfad definiert ist (und es sich nicht um den Standardpfad für mehrfaches Auschecken handelt), enthält diese Variable den genauen Pfad zum Selbst-Repository.
Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.Repository.ID Der eindeutige Bezeichner des Repositorys.

Dies ändert sich auch dann nicht, wenn der Name des Repositorys dies tut.

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

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.Repository.Provider Der Typ des auslösenden Repositorys.
  • TfsGit: TfsGit
  • TfsVersionControl: TfsVersionControl
  • Git: Git-Repository, das auf einem externen Server gehostet wird
  • GitHub
  • Svn: Subversion
Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.Repository.Tfvc.Workspace Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird.


Wenn z. B. Agent.BuildDirectory ist c:\agent_work\12 und der Agent.Id 8 ist, könnte der Arbeitsbereichsname folgende sein: ws_12_8

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.Repository.Uri Die URL für das auslösende Repository. Beispiel: Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag. 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 Branch des auslösenden Repositorys, für das der Build in die Warteschlange gestellt wurde. Einige Beispiele:
  • Git-Repository-Branch: refs/heads/master
  • Git-Repository-Pull Request: refs/pull/1/merge
  • TFVC-Repository-Branch: $/teamproject/main
  • Einchecken des TFVC-Repositorys: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC-Repository-Shelveset-Build: 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ägstriche ( / ) durch Unterstriche _ ersetzt.

Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheck-Build ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummerformat verwenden.
Ja
Build.SourceBranchName Der Name des Branchs im auslösenden Repository, für das der Build in die Warteschlange gestellt wurde.
  • Git-Repositoryverzweigung oder Pull Request: Das letzte Pfadsegment im Verweis. In diesem Wert refs/heads/master ist beispielsweise master . In refs/heads/feature/tools diesem Wert ist tools .
  • TFVC-Repository-Branch: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert $/teamproject/main ist beispielsweise main .
  • Der TfVC-Repository-Gated Check-In- oder Shelveset-Build ist der Name des Shelvesets. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheck-Build ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummerformat verwenden.
Ja
Build.SourcesDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien.

Wichtiger Hinweis: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code. Wenn Sie mehrere Repositorys auschecken, wird auf den Standardwert zurückverwendet, d. h. , auch wenn das repository self (primary) in einen benutzerdefinierten Pfad ausgecheckt wird, der sich von seinem Multi-Checkout-Standardpfad unterscheidet (in dieser Hinsicht unterscheidet sich die Variable vom Verhalten der $(Pipeline.Workspace)/s$(Pipeline.Workspace)/s/<RepoName> Variablen Build.Repository.LocalPath).

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
Build.SourceVersion Die neueste Versionskontrolle des auslösenden Repositorys, das in diesem Build enthalten ist. Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag. Ja
Build.SourceVersionMessage Der Kommentar des Commits oder Changesets für das auslösende Repository. Wir kürzen die Nachricht auf die erste Zeile oder auf 200 Zeichen, was kürzer ist.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag. Außerdem ist diese Variable nur auf Schrittebene verfügbar und weder in der Auftrags- noch auf der Stufenebene verfügbar (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 Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit zur Verwendung dieses Ordners besteht in der Veröffentlichung Ihrer Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte 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 im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
Build.Repository.Git.SubmoduleCheckout Der Wert, den Sie auf der Registerkarte Repository für Die Auschecken-Submoduleausgewählt haben. Wenn mehrere Repositorys ausgecheckt sind, verfolgt dieser Wert die Einstellung des auslösenden Repositorys nach.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.SourceTfvcShelveset Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle.


Wenn Sie einen geschlossenen Build oder einen Shelveset-Buildausführen, wird dies auf den Namen des Von Ihnen zu erstellenden Shelvesets festgelegt.

Hinweis: Diese Variable gibt einen Wert zurück, der für die Buildnutzung in einem Buildnummerformat ungültig ist.
Nein
Build.TriggeredBy.BuildId Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf die BuildID des auslösenden Build festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildabschlusstrigger ausgelöst.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.TriggeredBy.DefinitionId Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf die DefinitionID des auslösenden Build festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildabschlusstrigger ausgelöst.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.TriggeredBy.DefinitionName Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildabschlusstrigger ausgelöst.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.TriggeredBy.BuildNumber Wenn der Build von einem anderen Build ausgelöst wurde,wird diese Variable auf die Nummer des auslösenden Build festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildabschlusstrigger ausgelöst.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Build.TriggeredBy.ProjectID Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf die ID des Projekts festgelegt, das den auslösenden Build enthält. In klassischen Pipelines wird diese Variable durch einen Buildabschlusstrigger ausgelöst.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein
Common.TestResultsDirectory Der lokale Pfad auf dem Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Nein

Pipelinevariablen (DevOps Server 2020)

VariableBeschreibung
Pipeline.Workspace Arbeitsbereichsverzeichnis für eine bestimmte Pipeline. Diese Variable hat den gleichen Wert wie Agent.BuildDirectory .

Beispiel: /home/vsts/work/1.

Variablen des Bereitstellungsauftrags (DevOps Server 2020)

Diese Variablen gelten für einen bestimmten Bereitstellungsauftrag und werden nur zur Auftragsausführungszeit aufgelöst.

VariableBeschreibung
Environment.Name Name der Umgebung, die im Bereitstellungsauftrag zum Ausführen der Bereitstellungsschritte und aufzeichnen des Bereitstellungsverlaufs als Ziel ist. Beispiel: smarthotel-dev.
Environment.Id ID der Umgebung, die im Bereitstellungsauftrag als Ziel ausgewählt ist. Beispiel: 10.
Environment.ResourceName Name der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag zum Ausführen der Bereitstellungsschritte und Aufzeichnen des Bereitstellungsverlaufs als Ziel ausgewählt ist. Dies ist beispielsweise bookings ein Kubernetes-Namespace, der der Umgebung als Ressource hinzugefügt smarthotel-dev wurde.
Environment.ResourceId ID der spezifischen Ressource innerhalb der Umgebung, die im Bereitstellungsauftrag zum Ausführen der Bereitstellungsschritte als Ziel ausgewählt ist. Beispiel: 4.

Systemvariablen (DevOps Server 2020)

VariableBeschreibungIn 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 im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Ja
System.CollectionId Die GUID der TFS-Sammlung oder Azure DevOps Organisation Ja
System.CollectionUri Eine Zeichenfolge Team Foundation Server Auflistungs-URI. Ja
System.DefaultWorkingDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Nein
System.DefinitionId Die ID der Buildpipeline. Ja
System.HostType Legen Sie auf fest, wenn es sich build bei der Pipeline um einen Build handelt. Für ein Release gelten die Werte deployment für einen Bereitstellungsgruppenauftrag, gates während der Auswertung von Gates und für andere Aufträge release (Ohne Agent und Agent). Ja
System.JobAttempt Legen Sie beim ersten Versuch dieses Auftrags auf 1 fest, und wird jedes Mal inkrementiert, wenn der Auftrag wiederholt wird. Nein
System.JobDisplayName Der lesbare Name, der einem Auftrag gegeben wird. Nein
System.JobId Ein eindeutiger Bezeichner für einen einzelnen Versuch eines einzelnen Auftrags. Der Wert ist für die aktuelle Pipeline eindeutig. Nein
System.JobName Der Name des Auftrags, der normalerweise zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet wird. Nein
System.PhaseAttempt Legen Sie beim ersten Versuch dieser Phase auf 1 fest, und wird jedes Mal inkrementiert, wenn der Auftrag wiederholt wird.

Hinweis: "Phase" ist ein größtenteils redundantes Konzept, das die Entwurfszeit für einen Auftrag darstellt (während der Auftrag die Laufzeitversion einer Phase war). Wir haben das Konzept der "Phase" größtenteils aus Azure Pipelines entfernt. Matrixaufträge und Aufträge mit mehreren Konfigurationen sind der einzige Ort, an dem sich "phase" noch von "job" unterscheidet. Eine Phase kann mehrere Aufträge instanziieren, die sich nur in ihren Eingaben unterscheiden.
Nein
System.PhaseDisplayName Der lesbare Name, der einer Phase gegeben wird. Nein
System.PhaseName Ein zeichenfolgenbasierter Bezeichner für einen Auftrag, der in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet wird. Nein
System.StageAttempt Legen Sie beim ersten Versuch dieser Phase auf 1 fest, und wird jedes Mal inkrementiert, wenn der Auftrag wiederholt wird. Nein
System.StageDisplayName Der lesbare Name, der einer Phase gegeben wird. Nein
System.StageName Ein zeichenfolgenbasierter Bezeichner für eine Phase, der in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet wird. Ja
System.PullRequest.IsFork Wenn der Pull Request von einem Fork des Repositorys stammt, wird diese Variable auf True festgelegt. Andernfalls wird sie auf False festgelegt. Ja
System.PullRequest.PullRequestId Die ID des Pull Requests, der diesen Build verursacht hat. Ein Beispiel für die Camel-Case-Schreibweise lautet: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PRausgeführt wurde, der von einer Branchrichtlinie betroffen ist. Nein
System.PullRequest.PullRequestNumber Die Nummer des Pull Requests, der diesen Build verursacht hat. Diese Variable wird für Pull Requests von GitHub mit einer anderen Pull Request-ID und Pull Request-Nummer aufgefüllt. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn der PR von einer Branchrichtlinie betroffen ist. Nein
System.PullRequest.SourceBranch Der Branch, der in einem Pull Request überprüft wird. Ein Beispiel für die Camel-Case-Schreibweise lautet: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR, der von einer Branchrichtlinie betroffen ist, wurde. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn der PR von einer Branchrichtlinie betroffen ist. Nein
System.PullRequest.SourceRepositoryURI Die URL des Repositorys, das den Pull Request enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject. Nein
System.PullRequest.TargetBranch Der Branch, der das Ziel eines Pull Requests ist. Beispiel: refs/heads/master Wenn sich Ihr Repository in einem master Azure Repos, wenn sich Ihr Repository in einem GitHub. Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR, der von einer Branchrichtlinie betroffen ist, wurde. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn der PR von einer Branchrichtlinie betroffen ist. Nein
System.TeamFoundationCollectionUri Der URI der Team Foundation-Sammlung. Beispiel: https://dev.azure.com/fabrikamfiber/

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 Wird auf True festgelegt, wenn das Skript von einer Buildaufgabe ausgeführt wird.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 Bezeichnung oder ein Tag der Versionskontrolle anzuwenden.

VariableBeschreibung
Agent.BuildDirectory

Der lokale Pfad auf dem 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. Dieser enthält die Agent-Software. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobName Der Name des ausgeführten Auftrags. Dies ist normalerweise "Job" oder "__default", aber in Szenarien mit mehreren Konfigurationen ist die Konfiguration.
Agent.JobStatus Der Status des Build.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Auf die Umgebungsvariable sollte als verwiesen AGENT_JOBSTATUS werden. Die ältere agent.jobstatus ist aus Gründen der Abwärtskompatibilität verfügbar.

Agent.MachineName Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name

Der Name des Agents, der beim Pool registriert ist.

Wenn Sie einen selbstge 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 ausführen, werden auf dem Agenthost und dem Container möglicherweise andere Betriebssysteme ausgeführt.
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 Tasks wie z. B. .NET Core-CLI verwendet, um temporäre Elemente wie Testergebnisse vor der Veröffentlichung zu enthalten.
Agent.ToolsDirectory Das Verzeichnis, das von Aufgaben wie dem Node Tool-Installer und der Python-Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis hinzu, PATH damit sie von nachfolgenden Buildschritten verwendet werden können.

Erfahren Sie mehr über die Verwaltung dieses Verzeichnisses auf einem selbstge gehosteten Agent.
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work.

Es ist nicht garantiert, dass dieses Verzeichnis von Pipelineaufgaben (z. B. bei Zuordnung zu einem Container)

Buildvariablen (DevOps Server 2019)


VariableBeschreibung
Build.ArtifactStagingDirectory

Der lokale Pfad auf dem Agent, in den Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit zur Verwendung dieses Ordners besteht in der Veröffentlichung Ihrer Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte 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 im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Build.BuildId Die ID des Datensatzes für den abgeschlossenen Build.
Build.BuildNumber Der Name des abgeschlossenen Build. Sie können das Buildnummerformat angeben, das diesen Wert in den Pipelineoptionen generiert.

Diese Variable wird normalerweise verwendet, um sie in das Bezeichnungsformat zu ändern, das Sie auf der Registerkarte Repository angeben.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen kann das Bezeichnungsformat nicht verwendet werden.



Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Build.BuildUri Der URI für den Build. Ein Beispiel für die Camel-Case-Schreibweise lautet: vstfs:///Build/Build/1430.

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

Standardmäßig sind keine neuen Buildpipelines für die Bereinigung dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um ihn auf der Registerkarte Repository zu bereinigt.

Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work\1\b.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.DefinitionName Der Name der Buildpipeline.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen kann das Bezeichnungsformat nicht verwendet werden.

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 kann das Bezeichnungsformat nicht verwendet werden.

Build.QueuedById Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.Reason Das Ereignis, das die Ausführung des Build verursacht hat.
  • Manual: Ein Benutzer hat den Build manuell in die Warteschlange gestellt.
  • IndividualCI: IndividualCI die durch einen Git-Push oder ein TFVC-Einchecken ausgelöst wird.
  • BatchedCI: BatchedCI ausgelöst durch einen Git-Push oder ein TFVC-Einchecken, und die Batch-Änderungen wurden ausgewählt.
  • Schedule: Schedule Trigger.
  • ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Shelvesets manuell in die Warteschlange gestellt.
  • CheckInShelveset: CheckInShelveset
  • PullRequest: Der Build wurde durch eine Git-Branchrichtlinie ausgelöst, die einen Build erfordert.
  • BuildCompletion: Der Build wurde BuildCompletion
Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Branchrichtlinien.
Build.Repository.Clean Der Wert, den Sie in den Einstellungen des Quellrepositorys für Bereinigt ausgewählt haben.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.LocalPath

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

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

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Diese Variable ist synonym mit Build.SourcesDirectory.

Build.Repository.Name Der Name des Repositorys.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Provider Der Typ des Repositorys, das Sie ausgewählt haben.
  • TfsGit: TfsGit
  • TfsVersionControl: TfsVersionControl
  • Git: Git-Repository, das auf einem externen Server gehostet wird
  • GitHub
  • Svn: Subversion
Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Tfvc.Workspace Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird.


Wenn z. B. Agent.BuildDirectory und Agent.Id ist, kann der c:\agent_work\128 Arbeitsbereichsname wie der folgende sein: ws_12_8

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Uri Die URL für das Repository. Beispiel: Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.RequestedFor Siehe "Wie werden die Identitätsvariablen festgelegt?".

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen kann das Bezeichnungsformat nicht verwendet werden.

Build.RequestedForEmail Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.RequestedForId Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.SourceBranch Der Branch, für den der Build in die Warteschlange gestellt wurde. Einige Beispiele:
  • Git-Repository-Branch: refs/heads/master
  • Git-Repository-Pull Request: refs/pull/1/merge
  • TFVC-Repository-Branch: $/teamproject/main
  • Einchecken des TFVC-Repositorys: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC-Repository-Shelveset-Build: myshelveset;username@live.com
Wenn Sie diese Variable im Buildnummerformat verwenden, werden die Schrägstriche ( / ) durch Unterstriche _ ersetzt.

Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheck-Build ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummerformat verwenden.
Build.SourceBranchName Der Name des Branchs, für den der Build in die Warteschlange gestellt wurde.
  • Git-Repositoryverzweigung oder Pull Request: Das letzte Pfadsegment im Verweis. In diesem Wert refs/heads/master ist beispielsweise master . In refs/heads/feature/tools diesem Wert ist tools .
  • TFVC-Repository-Branch: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert ist z. $/teamproject/mainmain B. .
  • TfVC Repo Gated Check-In oder Shelveset Build ist der Name des Shelvesets. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheckbuild ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummernformat verwenden.
Build.SourcesDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Diese Variable ist synonym mit Build.Repository.LocalPath.

Build.SourceVersion Die neueste Versionskontrolle, die in diesem Build enthalten ist. Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.SourceVersionMessage Der Kommentar des Commits oder Changesets. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen, je nachdem, welcher Wert kürzer ist.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

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

Build.StagingDirectory

Der lokale Pfad auf dem Agent, in den artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit, diesen Ordner zu verwenden, besteht darin, Ihre Buildartefakte mit den Aufgaben Kopieren von Dateien und Veröffentlichen von Buildartefakten 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.

Weitere Informationen finden Sie unter Artifacts in Azure Pipelines.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Build.Repository.Git.SubmoduleCheckout Der Wert, den Sie für die Untermodule "Auschecken" auf der Registerkarte "Repository"ausgewählt haben.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.SourceTfvcShelveset Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist.


Wenn Sie einen geschlossenen Build oder einen Shelvesetbuildausführen, wird dies auf den Namen des von Ihnen erstellten Shelvesets festgelegt.

Hinweis: Diese Variable ergibt einen Wert, der für die Buildverwendung in einem Buildnummernformat ungültig ist.
Build.TriggeredBy.BuildId Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf die BuildID des auslösenden Builds festgelegt.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.TriggeredBy.DefinitionId Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.TriggeredBy.DefinitionName Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.TriggeredBy.BuildNumber Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf die Nummer des auslösenden Builds festgelegt.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.TriggeredBy.ProjectID Wenn der Build von einem anderen Build ausgelöstwurde, wird diese Variable auf die ID des Projekts festgelegt, das den auslösenden Build enthält.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Common.TestResultsDirectory Der lokale Pfad auf dem Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Systemvariablen (DevOps Server 2019)

VariableBeschreibung
System.AccessToken Verwenden Sie das OAuth-Token, um auf die REST-API zuzugreifen.

Verwenden Sie System.AccessToken aus YAML-Skripts.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
System.CollectionId Die GUID der TFS-Sammlung oder Azure DevOps Organisation
System.DefaultWorkingDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

System.DefinitionId Die ID der Buildpipeline.
System.HostType Legen Sie auf fest, wenn es sich build bei der Pipeline um einen Build handelt. Für ein Release gelten die Werte deployment für einen Bereitstellungsgruppenauftrag und release für einen -Agentauftrag.
System.PullRequest.IsFork Wenn der Pull Request von einem Fork des Repositorys stammt, wird diese Variable auf True festgelegt. Andernfalls wird sie auf False festgelegt.
System.PullRequest.PullRequestId Die ID des Pull Requests, der diesen Build verursacht hat. Ein Beispiel für die Camel-Case-Schreibweise lautet: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git PR ausgeführt wurde, der von einer Branchrichtlinie betroffenist.)
System.PullRequest.PullRequestNumber Die Nummer des Pull Requests, der diesen Build verursacht hat. Diese Variable wird für Pull Requests von GitHub mit einer anderen Pull Request-ID und Pull Request-Nummer aufgefüllt.
System.PullRequest.SourceBranch Der Branch, der in einem Pull Request überprüft wird. Ein Beispiel für die Camel-Case-Schreibweise lautet: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git PR ausgeführt wurde, der von einer Branchrichtlinie betroffenist.)
System.PullRequest.SourceRepositoryURI Die URL zum Repository, das den Pull Request enthält. Ein Beispiel für die Camel-Case-Schreibweise lautet: https://dev.azure.com/ouraccount/_git/OurProject. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Azure Repos Git PR ausgeführt wurde, der von einer Branchrichtlinie betroffenist. Es wird nicht für GitHub PRs initialisiert.)
System.PullRequest.TargetBranch Der Branch, der das Ziel eines Pull Requests ist. Ein Beispiel für die Camel-Case-Schreibweise lautet: refs/heads/master. Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PRausgeführt wurde, der von einer Branchrichtlinie betroffen ist.
System.TeamFoundationCollectionUri Der URI der Team Foundation-Sammlung. Ein Beispiel für die Camel-Case-Schreibweise lautet: https://dev.azure.com/fabrikamfiber/.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 auf True fest, wenn das Skript von einem Buildtask ausgeführt wird.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Agent-Variablen (TFS 2018)

Hinweis

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

VariableBeschreibung
Agent.BuildDirectory

Der lokale Pfad auf dem 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 Agent-Software. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobStatus Der Status des Builds.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Auf die Umgebungsvariable sollte als verwiesen AGENT_JOBSTATUS werden. Der ältere agent.jobstatus ist aus Gründen der Abwärtskompatibilität verfügbar.

Agent.MachineName Der Name des Computers, auf dem der Agent installiert ist.
Agent.Name

Der Name des Agents, der beim 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 Tasks wie .NET Core-CLI Aufgabe verwendet, um temporäre Elemente wie Testergebnisse vor der Veröffentlichung zu speichern.
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 selbstgehosteten Agent.
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work.

Buildvariablen (TFS 2018)


VariableBeschreibung
Build.ArtifactStagingDirectory Der lokale Pfad auf dem Agent, in den artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden.

Der lokale Pfad auf dem Agent, in den artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit, diesen Ordner zu verwenden, besteht darin, Ihre Buildartefakte mit den Aufgaben Kopieren von Dateien und Veröffentlichen von Buildartefakten 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.

Weitere Informationen finden Sie unter Artifacts in Azure Pipelines.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

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

Eine typische Verwendung dieser Variablen besteht darin, sie in das Bezeichnungsformat zu machen, das Sie auf der Registerkarte Repositoryangeben.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.



Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Tag für die Versionskontrolle.

Build.BuildUri Der URI für den Build. Ein Beispiel für die Camel-Case-Schreibweise lautet: vstfs:///Build/Build/1430.

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

Standardmäßig sind keine neuen Buildpipelines zum Bereinigen dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um ihn auf der Registerkarte Repositoryzu bereinigen.

Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work\1\b.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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.Reason Das Ereignis, das die Ausführung des Builds verursacht hat.
  • Manual: Ein Benutzer hat den Build manuell über die Benutzeroberfläche oder einen API-Aufruf in die Warteschlange eingereiht.
  • IndividualCI: IndividualCI ausgelöst durch einen Git-Push oder ein TFVC-Einchecken.
  • BatchedCI: BatchedCI die durch einen Git-Push oder ein TFVC-Einchecken ausgelöst wird, und die Batch-Änderungen wurden ausgewählt.
  • Schedule: Schedule Trigger.
  • ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Shelvesets manuell in die Warteschlange eingereiht.
  • CheckInShelveset: CheckInShelveset
  • PullRequest: Der Build wurde durch eine Git-Branchrichtlinie ausgelöst, die einen Build erfordert.
Weitere Informationen finden Sie unter Erstellen von Pipelinetriggern, Verbessern der Codequalität mit Branchrichtlinien.
Build.Repository.Clean Der Wert, den Sie für Bereinigen in den Quell-Repositoryeinstellungenausgewählt haben.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.LocalPath

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Diese Variable ist synonym mit Build.SourcesDirectory.

Build.Repository.Name Der Name des Repositorys.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Provider Der Typ des ausgewählten Repositorys.
  • TfsGit: TfsGit
  • TfsVersionControl: TfsVersionControl
  • Git: Git-Repository, das auf einem externen Server gehostet wird
  • Svn: Subversion
Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Tfvc.Workspace Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird.

Wenn z. B. Agent.BuildDirectory ist c:\agent_work\12 und die Agent.Id 8 ist, könnte der Arbeitsbereichsname folgende sein: ws_12_8

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 Branch, für den der Build in die Warteschlange eingereiht wurde. Einige Beispiele:
  • Git-Repository-Branch: refs/heads/master
  • Pull Request des Git-Repositorys: refs/pull/1/merge
  • TFVC-Repository-Branch: $/teamproject/main
  • Einchecken durch TFVC-Repository: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC repo shelveset build (BUILD des TFVC-Repository-Shelvesets): myshelveset;username@live.com
Wenn Sie diese Variable im Buildnummernformat verwenden, werden die Schrägstriche ( / ) durch Unterstriche _ ersetzt.

Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheckbuild ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummernformat verwenden.
Build.SourceBranchName Der Name des Branchs, für den der Build in die Warteschlange eingereiht wurde.
  • Git Repo Branch oder Pull Request: Das letzte Pfadsegment in der Referenz. In diesem Wert ist z. refs/heads/mastermaster B. . In refs/heads/feature/tools diesem Wert ist tools .
  • TFVC-Repositoryverzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert ist z. $/teamproject/mainmain B. .
  • TfVC Repo Gated Check-In oder Shelveset Build ist der Name des Shelvesets. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheckbuild ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummernformat verwenden.
Build.SourcesDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Diese Variable ist synonym mit Build.Repository.LocalPath.

Build.SourceVersion Die neueste Versionskontrolle, die in diesem Build enthalten ist. Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.SourceVersionMessage Der Kommentar des Commits oder Changesets. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen, je nachdem, welcher Wert kürzer ist.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

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

Build.StagingDirectory

Der lokale Pfad auf dem Agent, in den artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit, diesen Ordner zu verwenden, besteht darin, Ihre Buildartefakte mit den Aufgaben Kopieren von Dateien und Veröffentlichen von Buildartefakten 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.

Weitere Informationen finden Sie unter Artifacts in Azure Pipelines.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Build.Repository.Git.SubmoduleCheckout Der Wert, den Sie für die Untermodule "Auschecken" auf der Registerkarte "Repository"ausgewählt haben.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.SourceTfvcShelveset Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist.

Wenn Sie einen geschlossenen Build oder einen Shelvesetbuildausführen, wird dies auf den Namen des von Ihnen erstellten Shelvesets festgelegt.

Hinweis: Diese Variable ergibt einen Wert, der für die Buildverwendung in einem Buildnummernformat 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 im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Systemvariablen (TFS 2018)

VariableBeschreibung
System.AccessToken Verwenden Sie das OAuth-Token, um auf die REST-API zuzugreifen.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
System.CollectionId Die GUID der TFS-Sammlung oder Azure DevOps Organisation
System.DefaultWorkingDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

System.DefinitionId Die ID der Buildpipeline.
System.HostType Legen Sie auf fest, wenn es sich bei der Pipeline um einen Build handelt oder wenn es sich bei build der Pipeline um ein Release release handelt.
System.PullRequest.IsFork Wenn der Pull Request von einem Fork des Repositorys stammt, wird diese Variable auf True festgelegt. Andernfalls wird sie auf False festgelegt. Verfügbar in TFS 2018.2.
System.PullRequest.PullRequestId Die ID des Pull Requests, der diesen Build verursacht hat. Ein Beispiel für die Camel-Case-Schreibweise lautet: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git PR ausgeführt wurde, der von einer Branchrichtlinie betroffenist.)
System.PullRequest.SourceBranch Der Branch, der in einem Pull Request überprüft wird. Ein Beispiel für die Camel-Case-Schreibweise lautet: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git PR ausgeführt wurde, der von einer Branchrichtlinie betroffenist.)
System.PullRequest.SourceRepositoryURI Die URL zum Repository, das den Pull Request enthält. Ein Beispiel für die Camel-Case-Schreibweise lautet: http://our-server:8080/tfs/DefaultCollection/_git/OurProject. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Azure Repos Git PR ausgeführt wurde, der von einer Branchrichtlinie betroffenist.)
System.PullRequest.TargetBranch Der Branch, der das Ziel eines Pull Requests ist. Ein Beispiel für die Camel-Case-Schreibweise lautet: refs/heads/master. Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PRausgeführt wurde, der von einer Branchrichtlinie betroffen ist.
System.TeamFoundationCollectionUri Der URI der Team Foundation-Sammlung. Ein Beispiel für die Camel-Case-Schreibweise lautet: http://our-server:8080/tfs/DefaultCollection/.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 auf True fest, wenn das Skript von einem Buildtask ausgeführt wird.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Agent-Variablen (TFS 2017)

Hinweis

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

VariableBeschreibung
Agent.BuildDirectory

Der lokale Pfad auf dem Agent, in dem alle Ordner für eine bestimmte Buildpipeline erstellt werden.

Beispiel: c:\agent_work\1

Agent.ComputerName Der Name des Computers, auf dem der Agent installiert ist.
Agent.HomeDirectory Das Verzeichnis, in dem der Agent installiert ist. Dies enthält die Agent-Software. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobStatus Der Status des Builds.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Auf die Umgebungsvariable sollte als verwiesen AGENT_JOBSTATUS werden. Der ältere agent.jobstatus ist aus Gründen der Abwärtskompatibilität verfügbar.

Agent.Name

Der Name des Agents, der beim Pool registriert ist.

Dieser Name wird von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.

Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work.

Buildvariablen (TFS 2017)


VariableBeschreibung
Build.ArtifactStagingDirectory Der lokale Pfad auf dem Agent, in den Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden.

Der lokale Pfad auf dem Agent, in den Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit zur Verwendung dieses Ordners besteht in der Veröffentlichung Ihrer Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte 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 im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Build.BuildId Die ID des Datensatzes für den abgeschlossenen Build.
Build.BuildNumber Der Name des abgeschlossenen Build. Sie können das Buildnummerformat angeben, das diesen Wert in den Pipelineoptionen generiert.

Diese Variable wird normalerweise verwendet, um sie in das Bezeichnungsformat zu ändern, das Sie auf der Registerkarte Repository angeben.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen kann das Bezeichnungsformat nicht verwendet werden.



Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Versionskontrollestag.

Build.BuildUri Der URI für den Build. Ein Beispiel für die Camel-Case-Schreibweise lautet: vstfs:///Build/Build/1430.

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

Standardmäßig sind keine neuen Buildpipelines für die Bereinigung dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um ihn auf der Registerkarte Repository zu bereinigt.

Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work\1\b.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.DefinitionName Der Name der Buildpipeline.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen kann das Bezeichnungsformat nicht verwendet werden.

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 kann das Bezeichnungsformat nicht verwendet werden.

Build.QueuedById Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.Reason Das Ereignis, das die Ausführung des Build verursacht hat. Verfügbar in TFS 2017.3.
  • Manual: Ein Benutzer hat den Build manuell in die Warteschlange gestellt.
  • IndividualCI: IndividualCI die durch einen Git-Push oder ein TFVC-Einchecken ausgelöst wird.
  • BatchedCI: BatchedCI ausgelöst durch einen Git-Push oder ein TFVC-Einchecken, und die Batch-Änderungen wurden ausgewählt.
  • Schedule: Schedule Trigger.
  • ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Shelvesets manuell in die Warteschlange gestellt.
  • CheckInShelveset: CheckInShelveset
  • PullRequest: Der Build wurde durch eine Git-Branchrichtlinie ausgelöst, die einen Build erfordert.
Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Branchrichtlinien.
Build.Repository.Clean Der Wert, den Sie in den Einstellungen des Quellrepositorys für Bereinigt ausgewählt haben.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.LocalPath

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

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

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Diese Variable ist synonym mit Build.SourcesDirectory.

Build.Repository.Name Der Name des Repositorys.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Provider Der Typ des Repositorys, das Sie ausgewählt haben.
  • TfsGit: TfsGit
  • TfsVersionControl: TfsVersionControl
  • Git: Git-Repository, das auf einem externen Server gehostet wird
  • Svn: Subversion
Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Tfvc.Workspace Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird.

Wenn z. B. Agent.BuildDirectory und Agent.Id ist, kann der c:\agent_work\128 Arbeitsbereichsname wie der folgende sein: ws_12_8

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 Branch, für den der Build in die Warteschlange eingereiht wurde. Einige Beispiele:
  • Git-Repository-Branch: refs/heads/master
  • Pull Request des Git-Repositorys: refs/pull/1/merge
  • TFVC-Repository-Branch: $/teamproject/main
  • Einchecken durch TFVC-Repository: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC repo shelveset build (BUILD des TFVC-Repository-Shelvesets): myshelveset;username@live.com
Wenn Sie diese Variable im Buildnummernformat verwenden, werden die Schrägstriche ( / ) durch Unterstriche _ ersetzt.

Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheckbuild ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummernformat verwenden.
Build.SourceBranchName Der Name des Branchs, für den der Build in die Warteschlange eingereiht wurde.
  • Git Repo Branch oder Pull Request: Das letzte Pfadsegment in der Referenz. In diesem Wert ist z. refs/heads/mastermaster B. . In refs/heads/feature/tools diesem Wert ist tools .
  • TFVC-Repositoryverzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert ist z. $/teamproject/mainmain B. .
  • TfVC Repo Gated Check-In oder Shelveset Build ist der Name des Shelvesets. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheckbuild ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummernformat verwenden.
Build.SourcesDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Diese Variable ist synonym mit Build.Repository.LocalPath.

Build.SourceVersion Die neueste Versionskontrolle, die in diesem Build enthalten ist. Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.SourceVersionMessage Der Kommentar des Commits oder Changesets. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen, je nachdem, welcher Wert kürzer ist.

Diese Variable ist im Agent-Bereich und kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

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

Build.StagingDirectory

Der lokale Pfad auf dem Agent, in den artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden. Beispiel: c:\agent_work\1\a

Eine typische Möglichkeit, diesen Ordner zu verwenden, besteht darin, Ihre Buildartefakte mit den Aufgaben Kopieren von Dateien und Veröffentlichen von Buildartefakten 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.

Weitere Informationen finden Sie unter Artifacts in Azure Pipelines.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Build.Repository.Git.SubmoduleCheckout Der Wert, den Sie für die Untermodule "Auschecken" auf der Registerkarte "Repository"ausgewählt haben.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.SourceTfvcShelveset Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist.

Wenn Sie einen geschlossenen Build oder einen Shelvesetbuildausführen, wird dies auf den Namen des von Ihnen erstellten Shelvesets festgelegt.

Hinweis: Diese Variable ergibt einen Wert, der für die Buildverwendung in einem Buildnummernformat 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 im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Systemvariablen (TFS 2017)

VariableBeschreibung
System.AccessToken Verwenden Sie das OAuth-Token, um auf die REST-API zuzugreifen.
System.CollectionId Die GUID der TFS-Sammlung oder Azure DevOps Organisation
System.DefaultWorkingDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

Standardmäßig aktualisieren neue Buildpipelines nur die geänderten Dateien. Sie können ändern, wie Dateien auf der Registerkarte Repositoryheruntergeladen werden.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

System.DefinitionId Die ID der Buildpipeline.
System.HostType Legen Sie auf fest, wenn es sich bei der Pipeline um einen Build handelt oder wenn es sich bei build der Pipeline um ein Release release handelt.
System.PullRequest.PullRequestId Die ID des Pull Requests, der diesen Build verursacht hat. Ein Beispiel für die Camel-Case-Schreibweise lautet: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git PR ausgeführt wurde, der von einer Branchrichtlinie betroffenist.)
System.PullRequest.SourceBranch Der Branch, der in einem Pull Request überprüft wird. Ein Beispiel für die Camel-Case-Schreibweise lautet: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git PR ausgeführt wurde, der von einer Branchrichtlinie betroffenist.)
System.PullRequest.SourceRepositoryURI Die URL zum Repository, das den Pull Request enthält. Ein Beispiel für die Camel-Case-Schreibweise lautet: http://our-server:8080/tfs/DefaultCollection/_git/OurProject. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Azure Repos Git PR ausgeführt wurde, der von einer Branchrichtlinie betroffenist.)
System.PullRequest.TargetBranch Der Branch, der das Ziel eines Pull Requests ist. Ein Beispiel für die Camel-Case-Schreibweise lautet: refs/heads/master. Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PRausgeführt wurde, der von einer Branchrichtlinie betroffen ist.
System.TeamFoundationCollectionUri Der URI der Team Foundation-Sammlung. Ein Beispiel für die Camel-Case-Schreibweise lautet: http://our-server:8080/tfs/DefaultCollection/.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 auf True fest, wenn das Skript von einem Buildtask ausgeführt wird.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Agent-Variablen (TFS 2015)

Hinweis

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

VariableBeschreibung
Agent.BuildDirectory

Der lokale Pfad auf dem Agent, in dem alle Ordner für eine bestimmte Buildpipeline erstellt werden.

Beispiel:

  • TFS 2015.4: C:\TfsData\Agents\Agent-MACHINENAME_work\1
  • Vom Benutzer installierter TFS 2015 RTM-Agent: C:\Agent_work\6c3842c6
  • Integrierter TFS 2015 RTM-Agent: C:\TfsData\Build_work\6c3842c6
Agent.HomeDirectory

Das Verzeichnis, in dem der Agent installiert ist. Dies enthält die Agent-Software.

Beispiel:

  • TFS 2015.4: C:\TfsData\Agents\Agent-MACHINENAME
  • Vom Benutzer installierter TFS 2015 RTM-Agent: C:\Agent
  • Integrierter TFS 2015 RTM-Agent: C:\Program Files\Microsoft Team Foundation Server 14.0\Build
Agent.Id Die ID der Momentaufnahme.
Agent.JobStatus Der Status des Builds.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Hinweis: Auf die Umgebungsvariable kann nur als verwiesen werden. AGENT_JOBSTATUS war in TFS 2015 nicht vorhanden.

Agent.MachineName Der Name des Computers, auf dem der Agent installiert ist. Diese Variable ist in TFS 2015.4und nicht in TFS 2015 RTMverfügbar.
Agent.Name

Der Name des Agents, der beim Pool registriert ist.

Dieser Name wird von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.

Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work.

Buildvariablen (TFS 2015)


VariableBeschreibung
Build.ArtifactStagingDirectory Der lokale Pfad auf dem Agent, in den artefakte kopiert werden, bevor sie an ihr Ziel gepusht werden.

Eine typische Möglichkeit, diesen Ordner zu verwenden, besteht darin, Ihre Buildartefakte mit den Aufgaben Kopieren von Dateien und Veröffentlichen von Buildartefakten zu veröffentlichen. Weitere Informationen finden Sie unter Artifacts in Azure Pipelines.

Beispiel:
  • TFS 2015.4: C:\TfsData\Agents\Agent-MACHINENAME_work\1\a
  • TFS 2015 RTM-Standard-Agent: C:\TfsData\Build_work\6c3842c6\artifacts
  • TFS 2015 RTM-Agent von Ihnen installiert: C:\Agent_work\6c3842c6\artifacts
Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen.

In TFS 2015.4sind Build.ArtifactStagingDirectory und Build.StagingDirectory austauschbar.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 Pipelineoptionengeneriert.

Eine typische Verwendung dieser Variablen besteht darin, sie in das Bezeichnungsformat zu machen, das Sie auf der Registerkarte Repositoryangeben.

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen schlägt das Bezeichnungsformat fehl.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil eines Versionskontrolltags.

Build.BuildUri Der URI für den Build. Ein Beispiel für die Camel-Case-Schreibweise lautet: vstfs:///Build/Build/1430.

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.BinariesDirectory Der lokale Pfad auf dem Agent, den Sie als Ausgabeordner für kompilierte Binärdateien verwenden können. Verfügbar in TFS 2015.4.

Standardmäßig sind keine neuen Buildpipelines zum Bereinigen dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um ihn auf der Registerkarte Repositoryzu bereinigen.

Beispiel: C:\TfsData\Agents\Agent-MACHINENAME_work\1\b

Diese Variable ist im Agent-Bereich. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einem Buildtask verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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.Repository.Clean Der Wert, den Sie in den Einstellungen des Quellrepositorys für Bereinigt ausgewählt haben.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.LocalPath

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

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

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Diese Variable ist synonym mit Build.SourcesDirectory.

Build.Repository.Name Der Name des Repositorys.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Provider Der Typ des Repositorys, das Sie ausgewählt haben.
  • TfsGit: TfsGit
  • TfsVersionControl: TfsVersionControl
  • Git: Git-Repository, das auf einem externen Server gehostet wird
  • Svn: Subversion (verfügbar auf TFS 2015.4)
Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Tfvc.Workspace Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle. Der Name des TFVC-Arbeitsbereichs, der vom Build-Agent verwendet wird.

Wenn z. B. Agent.BuildDirectory und der Agent.Id ist, kann der c:\agent_work\128 Arbeitsbereichsname wie der folgende sein: ws_12_8

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.RequestedFor Siehe "Wie werden die Identitätsvariablen festgelegt?".

Hinweis: Dieser Wert kann Leerzeichen oder andere ungültige Bezeichnungszeichen enthalten. In diesen Fällen kann das Bezeichnungsformat nicht verwendet werden.

Build.RequestedForId Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.SourceBranch Der Branch, für den der Build in die Warteschlange gestellt wurde. Einige Beispiele:
  • Git-Repository-Branch: refs/heads/master
  • Git-Repository-Pull Request: refs/pull/1/merge
  • TFVC-Repository-Branch: $/teamproject/main
  • Einchecken des TFVC-Repositorys: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC-Repository-Shelveset-Build: myshelveset;username@live.com
Wenn Sie diese Variable im Buildnummerformat verwenden, werden die Schrägstriche ( / ) durch Unterstriche _ ersetzt.

Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheck-Build ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummerformat verwenden.
Build.SourceBranchName Der Name des Branchs, für den der Build in die Warteschlange gestellt wurde.
  • Git-Repositoryverzweigung oder Pull Request: Das letzte Pfadsegment im Verweis. In diesem Wert refs/heads/master ist beispielsweise master . In refs/heads/feature/tools diesem Wert ist tools .
  • TFVC-Repository-Branch: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert $/teamproject/main ist beispielsweise main .
  • Der TfVC-Repository-Gated Check-In- oder Shelveset-Build ist der Name des Shelvesets. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: Wenn Sie in TFVC einen geschlossenen Eincheck-Build ausführen oder manuell ein Shelveset erstellen, können Sie diese Variable nicht im Buildnummerformat verwenden.
Build.SourcesDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

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

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Diese Variable ist synonym mit Build.Repository.LocalPath.

Build.SourcesDirectoryHash Hinweis: Diese Variable ist in TFS 2015 RTM verfügbar, aber nicht in TFS 2015.4.
Build.SourceVersion Die neueste Versionskontrolle, die in diesem Build enthalten ist. Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.SourceVersionMessage Der Kommentar des Commits oder Changesets. Wir kürzen die Nachricht auf die erste Zeile oder auf 200 Zeichen, was kürzer ist.

Diese Variable ist im Bereich des Agents und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

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

Build.StagingDirectory TFS 2015 RTM

Der lokale Pfad auf dem Agent, den Sie als Ausgabeordner für kompilierte Binärdateien verwenden können. Ein Beispiel für die Camel-Case-Schreibweise lautet: C:\TfsData\Build_work\6c3842c6\staging.

Standardmäßig sind keine neuen Buildpipelines für die Bereinigung dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um ihn auf der Registerkarte Repository zu bereinigt.

TFS 2015.4

Der lokale Pfad auf dem Agent, in den Artefakte kopiert werden, bevor sie an ihr Ziel verschoben werden. Beispiel: C:\TfsData\Agents\Agent-MACHINENAME_work\1\a

Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen.

Eine typische Möglichkeit zur Verwendung dieses Ordners besteht in der Veröffentlichung Ihrer Buildartefakte mit den Aufgaben Dateien kopieren und Buildartefakte veröffentlichen. Siehe Artifacts in Azure Pipelines.

In TFS 2015.4sind Build.ArtifactStagingDirectory und Build.StagingDirectory austauschbar.

Alle Versionen von TFS 2015

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.Repository.Git.SubmoduleCheckout Der Wert, den Sie auf der Registerkarte Repository für Die Auschecken-Submoduleausgewählt haben.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
Build.SourceTfvcShelveset Wird definiert, wenn Ihr Repository Team Foundation-Versionskontrolle.

Wenn Sie einen geschlossenen Build oder einen Shelveset-Buildausführen, wird dies auf den Namen des Von Ihnen zu erstellenden Shelvesets festgelegt.

Hinweis: Diese Variable gibt einen Wert zurück, der für die Buildnutzung in einem Buildnummerformat ungültig ist.
Common.TestResultsDirectory Der lokale Pfad auf dem Agent, in dem die Testergebnisse erstellt werden. Ein Beispiel für die Camel-Case-Schreibweise lautet: c:\agent_work\1\TestResults. Verfügbar in TFS 2015.4.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Systemvariablen (TFS 2015)

VariableBeschreibung
System.AccessToken Verfügbar in TFS 2015.4. Verwenden Sie das OAuth-Token, um auf die REST-API zuzugreifen.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
System.CollectionId Die GUID der TFS-Sammlung oder -Azure DevOps Organisation
System.DefaultWorkingDirectory

Der lokale Pfad auf dem Agent, in den Ihre Quellcodedateien heruntergeladen werden. Beispiel: c:\agent_work\1\s

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

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

System.DefinitionId Die ID der Buildpipeline.
System.HostType Legen Sie auf build fest, wenn es sich bei der Pipeline um einen Build handelt oder wenn es sich bei der Pipeline um ein Release release handelt.
System.PullRequest.PullRequestId Die ID des Pull Requests, der diesen Build verursacht hat. Ein Beispiel für die Camel-Case-Schreibweise lautet: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR,der von einer Branchrichtlinie betroffen ist, erstellt wurde.)
System.PullRequest.SourceBranch Der Branch, der in einem Pull Request überprüft wird. Ein Beispiel für die Camel-Case-Schreibweise lautet: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR,der von einer Branchrichtlinie betroffen ist, erstellt wurde.)
System.PullRequest.SourceRepositoryURI Die URL des Repositorys, das den Pull Request enthält. Ein Beispiel für die Camel-Case-Schreibweise lautet: http://our-server:8080/tfs/DefaultCollection/_git/OurProject. (Diese Variable wird nur initialisiert, wenn der Build aufgrund eines git Azure Repos PR von einer Branchrichtlinie betroffen ist.)
System.PullRequest.TargetBranch Der Branch, der das Ziel eines Pull Requests ist. Ein Beispiel für die Camel-Case-Schreibweise lautet: refs/heads/master. Diese Variable wird nur initialisiert, wenn der Build aufgrund eines Git-PR, der von einer Branchrichtlinie betroffen ist, wurde.
System.TeamFoundationCollectionUri Der URI der Team Foundation-Sammlung. Ein Beispiel für die Camel-Case-Schreibweise lautet: http://our-server:8080/tfs/DefaultCollection/.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.
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 Wird auf True festgelegt, wenn das Skript von einer Buildaufgabe ausgeführt wird.

Diese Variable ist im Bereich des Agents. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, jedoch nicht als Teil der Buildnummer oder als Versionskontrollestag.

Wie werden die Identitätsvariablen festgelegt?

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

Wenn der Build ausgelöst wird... Anschließend basieren die Werte Build.QueuedBy und Build.QueuedById auf... Anschließend basieren die Werte Build.RequestedFor und Build.RequestedForId auf...
In Git oder TFVC durch die Ci-Trigger (Continuous Integration) Die Systemidentität, z. B.: [DefaultCollection]\Project Collection Service Accounts Die Person, die die Änderungen mit pusht oder eincheckt hat.
Erstellen Sie in Git oder durch eine Branchrichtlinie. Die Systemidentität, z. B.: [DefaultCollection]\Project Collection Service Accounts Die Person, die die Änderungen überprüft hat.
In TFVC durch einen geschlossenen Einchecktrigger Die Person, die die Änderungen überprüft hat. Die Person, die die Änderungen überprüft 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 Warteschlangen-Build geklickt haben Sie Sie

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2015

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 praktische 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, die jedoch größtenteils für die interne Verwendung verwendet werden.

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

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

Für klassische Pipelines können Sie Releasevariablen in Ihren Bereitstellungsaufgaben verwenden, um die allgemeinen Informationen (z. B. Umgebungsname, Ressourcengruppe usw.) frei zu geben.

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 Repositorys auf dem Agent.

Diese Variable ändert, wie der Build-Agent die Quelle bereinigt. Weitere Informationen finden Sie unter Bereinigen des lokalen Repositorys auf dem Agent.

System.AccessToken

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

In YAML müssen Sie der Pipeline mithilfe einer Variablen System.AccessToken explizit zuordnen. 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 die Verwendung des System.AccessTokenSystem.AccessToken

System.Debug

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

  1. Bearbeiten Sie Ihre Pipeline.

  2. Wählen Sie Variablen aus.

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

    Legen Sie

  4. Speichern Sie die neue Variable.