Verwenden vordefinierter Variablen

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

Hinweis

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

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

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

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

Für klassische Pipelines können Sie Freigabevariablen in Ihren Bereitstellungsaufgaben verwenden, um die allgemeinen Informationen (z. B. – Umgebungsname, Ressourcengruppe usw.) freizugeben.

Erfahren Sie mehr über das Arbeiten mit Variablen.

Build.Clean

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

System.AccessToken

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

In YAML müssen Sie die Pipeline explizit mithilfe einer Variablen zuordnen System.AccessToken . Dies können Sie auf Schritt- oder Vorgangsebene ausführen:

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

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

System.Debug

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

  1. Bearbeiten Sie Ihre Pipeline.

  2. Wählen Sie Variablen aus.

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

    Festlegen des Systemdebugs auf

  4. Speichern Sie die neue Variable.

Agentvariablen (DevOps Services)

Hinweis

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

VariableBESCHREIBUNG
Agent.BuildDirectory

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

Beispiel: /home/vsts/work/1

Agent.ContainerMapping

Eine Zuordnung von Containerressourcennamen in YAML zu ihren Docker-IDs zur Laufzeit.

Beispiel:

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

Agent.HomeDirectory Das Verzeichnis, in dem der Agent installiert ist. Dies enthält die Agentsoftware. Beispiel: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobName Der Name des ausgeführten Auftrags. Dies ist in der Regel "Auftrag" oder "__default", aber in Multi-Config-Szenarien ist die Konfiguration.
Agent.JobStatus Der Status des Builds.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Die Umgebungsvariable sollte als AGENT_JOBSTATUS. Die ältere agent.jobstatus ist zur Abwärtskompatibilität verfügbar.

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

Der Name des Agents, der mit dem Pool registriert ist.

Wenn Sie einen selbst gehosteten Agent verwenden, wird dieser Name von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.

Agent.OS Das Betriebssystem des Agenthosts. Gültige Werte sind:
  • Windows_NT
  • Darwin
  • Linux
Wenn Sie in einem Container ausgeführt werden, kann der Agenthost und der Container verschiedene Betriebssysteme ausführen.
Agent.OSArchitecture Die Prozessorarchitektur des Betriebssystems des Agenthosts. Gültige Werte sind:
  • X86
  • X64
  • ARM
Agent.TempDirectory

Ein temporärer Ordner, der nach jedem Pipelineauftrag bereinigt wird. Dieses Verzeichnis wird von Aufgaben wie .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu halten, bevor sie veröffentlicht werden.

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

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

Erfahren Sie mehr über das Verwalten dieses Verzeichnisses auf einem selbst gehosteten Agent.
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Beispiel: c:\agent_work.

Hinweis: Dieses Verzeichnis ist nicht garantiert, dass durch Pipelineaufgaben geschrieben werden kann (z. B. wenn ein Container zugeordnet wird)

Buildvariablen (DevOps Services)


VariableBESCHREIBUNGVerfügbar in Vorlagen?
Build.ArtifactStagingDirectory

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

Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen " zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen.

Siehe Artefakte in Azure-Pipelines.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

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

Eine typische Verwendung dieser Variablen besteht darin, es teil des Bezeichnungsformats zu machen, das Sie auf der Repositoryregisterkarte angeben.

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



Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Nein
Build.BuildUri Der URI für den Build. Beispiel: vstfs:///Build/Build/1430.

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

Standardmäßig sind neue Buildpipelinen nicht zum Bereinigen dieses Verzeichnisses eingerichtet. Sie können Ihren Build definieren, um sie auf der Registerkarte "Repository" zu bereinigen.

Beispiel: c:\agent_work\1\b.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.ContainerId Die ID des Containers für Ihr Artefakte. Wenn Sie ein Artefakte in Ihrer Pipeline hochladen, wird es einem Container hinzugefügt, der für dieses bestimmte Artefakt spezifisch ist. Nein
Build.DefinitionName Der Name der Buildpipeline.

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

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

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

Ja
Build.QueuedById Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt. Ja
Build.Reason Das Ereignis, das dazu führte, dass der Build ausgeführt wurde.
  • Manual: Ein Benutzer hat den Build manuell in die Warteschlange gestellt.
  • IndividualCI: Kontinuierliche Integration (CI), die von einem Git-Push oder einem TFVC-Check-In ausgelöst wird.
  • BatchedCI: Kontinuierliche Integration (CI), die von einem Git-Push oder einer TFVC-Überprüfung ausgelöst wird, und die Batchänderungen wurden ausgewählt.
  • Schedule: Geplanter Trigger.
  • ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Regales manuell in die Warteschlange gestellt.
  • CheckInShelveset: Gated Check-In-Trigger .
  • PullRequest: Der Build wurde von einer Git-Verzweigungsrichtlinie ausgelöst, die einen Build erfordert.
  • ResourceTrigger: Der Build wurde durch einen Ressourcenauslöser ausgelöst oder durch einen anderen Build ausgelöst.
Weitere Informationen finden Sie unter Buildpipelinetrigger, Verbessern der Codequalität mit Verzweigungsrichtlinien.
Ja
Build.Repository.Clean Der Wert, den Sie für "Bereinigen " in den Quell-Repositoryeinstellungen ausgewählt haben.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.Repository.LocalPath

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

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

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

  • Wenn der Auscheckschritt für das Selbst-Repository (primär) keinen benutzerdefinierten Auscheckpfad definiert hat, oder der Auscheckpfad der Standardpfad $(Pipeline.Workspace)/s/<RepoName> für das Self-Repository ist, wird der Wert dieser Variable auf den Standardwert zurückgesetzt.$(Pipeline.Workspace)/s
  • Wenn der Auscheckschritt für das Selbst-Repository (primär) einen benutzerdefinierten Auscheckpfad definiert hat (und nicht der Standardpfad mit mehreren Auscheckvorgängen ist), enthält diese Variable den genauen Pfad zum Self-Repository.
Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.Repository.ID Der eindeutige Bezeichner des Repositorys.

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

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

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


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

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.Repository.Uri Die URL für das auslösende Repository. Beispiel: Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Nein
Build.RequestedFor Siehe "Wie werden die Identitätsvariablen festgelegt?".

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

Ja
Build.RequestedForEmail Siehe "Wie werden die Identitätsvariablen festgelegt?". Ja
Build.RequestedForId Siehe "Wie werden die Identitätsvariablen festgelegt?". Ja
Build.SourceBranch Der Zweig des auslösenden Repo, für den der Build in die Warteschlange gestellt wurde. Einige Beispiele:
  • Git-Repo-Zweig: refs/heads/main
  • Git-Repo-Pull-Anforderung: refs/pull/1/merge
  • TFVC-Repo-Zweig: $/teamproject/main
  • TFVC repo gated Check-In: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC-Repo-Regale erstellen: myshelveset;username@live.com
  • Wenn Ihre Pipeline durch ein Tag ausgelöst wird: refs/tags/your-tag-name
Wenn Sie diese Variable im Buildnummerformat verwenden, werden die Schrägstrichzeichen (/) durch Unterstriche _ersetzt).

Hinweis: In TFVC können Sie diese Variable nicht in Ihrem Buildformat verwenden, wenn Sie einen Gitter-Check-In-Build oder manuell erstellen.
Ja
Build.SourceBranchName Der Name der Verzweigung im auslösenden Repo, für den der Build in die Warteschlange gestellt wurde.
  • Git-Repo-Verzweigung, Pull-Anforderung oder Tag: Das letzte Pfadsegment in der Ref. In diesem Wert ist mainz. Brefs/heads/main. . In refs/heads/feature/tools diesem Wert ist tools. In refs/tags/your-tag-name diesem Wert ist your-tag-name.
  • TFVC-Repo-Verzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert ist mainz. B$/teamproject/main. .
  • TFVC-Repo-Eincheck- oder Regalset-Build ist der Name der Regale. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: In TFVC können Sie diese Variable nicht in Ihrem Buildformat verwenden, wenn Sie einen Gitter-Check-In-Build oder manuell erstellen.
Ja
Build.SourcesDirectory

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

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

Wichtig hinweis: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code. Wenn Sie mehrere Repositorys auschecken, wird sie auf den Standardwert zurückgesetzt, der $(Pipeline.Workspace)/sauch dann angezeigt wird, wenn das Selbst-Repository (primär) auf einen benutzerdefinierten Pfad ausgecheckt wird, der sich von seinem Standardpfad $(Pipeline.Workspace)/s/<RepoName> mit mehreren Auscheckvorgängen unterscheidet (in diesem Zusammenhang unterscheidet sich die Variable von dem Verhalten der Build.Repository.LocalPath-Variable).

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.

Nein
Build.SourceVersion Die neueste Versionssteuerungsänderung des auslösenden Repo, das in diesem Build enthalten ist. Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag. Ja
Build.SourceVersionMessage Der Kommentar des Commit- oder Änderungssets für das auslösende Repo. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen ab, was immer kürzer ist.

Dies Build.SourceVersionMessage entspricht der Nachricht zum Build.SourceVersion Commit. Der Build.SourceVersion Commit für einen PR-Build ist der Merge Commit (nicht der Commit für den Quellzweig).

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag. Darüber hinaus ist diese Variable nur auf Schrittebene verfügbar und ist weder in der Auftrags- noch auf Phasenebene verfügbar (d. h. die Nachricht wird erst extrahiert, wenn der Auftrag gestartet und der Code ausgecheckt wurde).

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

Nein
Build.StagingDirectory

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

Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen" zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, damit Sie es nicht selbst bereinigen müssen.

Siehe Artefakte in Azure-Pipelines.

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.

Nein
Build.Repository.Git.SubmoduleCheckout Der Wert, den Sie für Untermodule auschecken auf der Registerkarte "Repository" ausgewählt haben. Mit mehreren ausgecheckten Repos verfolgt dieser Wert die Einstellung des Auslösens des Repositorys.

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.
Nein
Build.SourceTfvcShelveset Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist.


Wenn Sie einen Gitterbau oder ein Regalet-Build ausführen, wird dies auf den Namen der Regale festgelegt, die Sie erstellen.

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

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.

Wenn Sie eine YAML-Pipeline mithilfe resourcesvon YAML auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.
Nein
Build.TriggeredBy.DefinitionId Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Build-Abschlussauslöser ausgelöst.

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.

Wenn Sie eine YAML-Pipeline mithilfe resourcesvon YAML auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.
Nein
Build.TriggeredBy.DefinitionName Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. In klassischen Pipelines wird diese Variable durch einen Build-Abschlussauslöser ausgelöst.

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.

Wenn Sie eine YAML-Pipeline mithilfe resourcesvon YAML auslösen, sollten Sie stattdessen die Ressourcenvariablen verwenden.
Nein
Build.TriggeredBy.BuildNumber Wenn der Build durch einen anderen Build ausgelöst wurde, wird diese Variable auf die Anzahl des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Build-Abschlussauslöser ausgelöst.

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.

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

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.

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

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.
Nein

Pipelinevariablen (DevOps Services)

VariableBESCHREIBUNG
Pipeline.Workspace Arbeitsbereichverzeichnis für eine bestimmte Pipeline. Diese Variable hat denselben Wert wie Agent.BuildDirectory.

Beispiel: /home/vsts/work/1.

Bereitstellungsauftragsvariablen (DevOps Services)

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

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

Systemvariablen (DevOps Services)

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 agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.
Ja
System.CollectionId Die GUID der TFS-Auflistung oder Azure DevOps-Organisation. Ja
System.CollectionUri Der URI der TFS-Auflistung oder Azure DevOps-Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/. Ja
System.DefaultWorkingDirectory

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

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

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Ja
System.DefinitionId Die ID der Buildpipeline. Ja
System.HostType Legen Sie fest build , ob die Pipeline ein Build ist. Für eine Version sind deployment die Werte für einen Bereitstellungsgruppenauftrag, gates während der Auswertung von Gates und release für andere (Agent- und Agentless)-Aufträge. Ja
System.JobAttempt Legen Sie auf 1 fest, wenn dieser Auftrag zum ersten Mal versucht wird, und erhöhen Sie jedes Mal, wenn der Auftrag erneut bearbeitet wird. Nein
System.JobDisplayName Der menschenlesbare Name, der einem Auftrag zugewiesen wird. Nein
System.JobId Ein eindeutiger Bezeichner für einen einzelnen Versuch eines einzelnen Auftrags. Der Wert ist eindeutig für die aktuelle Pipeline. Nein
System.JobName Der Name des Auftrags, der in der Regel zum Ausdruck von Abhängigkeiten und zum Zugriff auf Ausgabevariablen verwendet wird. Nein
System.PhaseAttempt Legen Sie zum ersten Mal fest, dass diese Phase versucht wird, und erhöhen Sie jedes Mal, wenn der Auftrag erneut ausgeführt wird.

Hinweis: "Phase" ist ein meist redundantes Konzept, das die Entwurfszeit für einen Auftrag darstellt (während der Auftrag die Laufzeitversion einer Phase war). Wir haben hauptsächlich das Konzept der "Phase" aus Azure-Pipelines entfernt. Matrix- und Multikonfigurationsaufträge sind der einzige Ort, an dem sich "Phase" immer noch von "Job" unterscheidet. Eine Phase kann mehrere Aufträge instanziieren, die sich nur in ihren Eingaben unterscheiden.
Nein
System.PhaseDisplayName Der menschliche lesbare Name, der einer Phase zugewiesen wird. Nein
System.PhaseName Ein Zeichenfolgenbasierter Bezeichner für einen Auftrag, der in der Regel zum Ausdruck von Abhängigkeiten und zum Zugreifen auf Ausgabevariablen verwendet wird. Nein
System.PlanId Ein Zeichenfolgenbasierter Bezeichner für einen einzelnen Pipelinelauf. Nein
System.PullRequest.IsFork Wenn die Pullanforderung von einer Freihandeingabe des Repositorys stammt, wird diese Variable auf Truefestgelegt. Andernfalls ist er auf False. Ja
System.PullRequest.PullRequestId Die ID der Pullanforderung, die diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist). Nein
System.PullRequest.PullRequestNumber Die Anzahl der Pullanforderung, die diesen Build verursacht hat. Diese Variable wird für Pullanforderungen von GitHub ausgefüllt, die eine andere Pull-Anforderungs-ID und Eine Pullanforderungsnummer aufweisen. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Verzweigungsrichtlinie betroffen ist. Nein
System.PullRequest.SourceBranch Die Verzweigung, die in einer Pullanforderung überprüft wird. Beispiel: refs/heads/users/raisa/new-feature für Azure Repos. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist). Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Verzweigungsrichtlinie betroffen ist. Nein
System.PullRequest.SourceRepositoryURI Die URL zum Repository, das die Pullanforderung enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject. Nein
System.PullRequest.TargetBranch Die Verzweigung, die das Ziel einer Pullanforderung ist. Beispiel: refs/heads/main Wenn sich Ihr Repository in Azure Repos befindet und main sich Ihr Repository in GitHub befindet. Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Verzweigungsrichtlinie betroffen ist. Nein
System.StageAttempt Legen Sie auf 1 fest, wenn diese Phase zum ersten Mal versucht wird, und erhöht jedes Mal, wenn der Auftrag erneut ausgeführt wird. Nein
System.StageDisplayName Der menschlich lesbare Name, der einer Stufe zugewiesen wird. Nein
System.StageName Ein Zeichenfolgen-basierter Bezeichner für eine Stufe, die in der Regel zum Ausdrucken von Abhängigkeiten und zugriff auf Ausgabevariablen verwendet wird. Nein
System.TeamFoundationCollectionUri Der URI der TFS-Auflistung oder Azure DevOps-Organisation. Beispiel: https://dev.azure.com/fabrikamfiber/.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Ja
System.TeamProject Der Name des Projekts, das diesen Build enthält. Ja
System.TeamProjectId Die ID des Projekts, zu dem dieser Build gehört. Ja
System.TimelineId Ein Zeichenfolgenbasierter Bezeichner für die Ausführungsdetails und Protokolle einer einzelnen Pipelineausführung. Nein
TF_BUILD Legen Sie fest True , ob das Skript von einer Buildaufgabe ausgeführt wird.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein

Überprüft Variablen (DevOps Services)

VariableBESCHREIBUNG
Checks.StageAttempt Legen Sie auf 1 fest, wenn diese Phase zum ersten Mal versucht wird, und erhöht jedes Mal, wenn die Phase erneut ausgeführt wird.

Diese Variable kann nur innerhalb einer Genehmigung verwendet oder auf eine Umgebung überprüft werden. Sie können z. B. innerhalb einer Aufruf-REST-API-Überprüfung verwenden$(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 Versionssteuerungsbezeichnung oder ein Tag anzuwenden.

VariableBESCHREIBUNG
Agent.BuildDirectory

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

Beispiel: /home/vsts/work/1

Agent.HomeDirectory Das Verzeichnis, in dem der Agent installiert ist. Dies enthält die Agentsoftware. Beispiel: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobName Der Name des ausgeführten Auftrags. Dies ist in der Regel "Auftrag" oder "__default", aber in Multi-Config-Szenarien ist die Konfiguration.
Agent.JobStatus Der Status des Builds.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Die Umgebungsvariable sollte als AGENT_JOBSTATUS. Die ältere agent.jobstatus ist zur Abwärtskompatibilität verfügbar.

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

Der Name des Agents, der mit dem Pool registriert ist.

Wenn Sie einen selbst gehosteten Agent verwenden, wird dieser Name von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.

Agent.OS Das Betriebssystem des Agenthosts. Gültige Werte sind:
  • Windows_NT
  • Darwin
  • Linux
Wenn Sie in einem Container ausgeführt werden, kann der Agenthost und der Container verschiedene Betriebssysteme ausführen.
Agent.OSArchitecture Die Betriebssystemprozessorarchitektur des Agenthosts. Gültige Werte sind:
  • X86
  • X64
  • ARM
Agent.TempDirectory

Ein temporärer Ordner, der nach jedem Pipelineauftrag bereinigt wird. Dieses Verzeichnis wird von Aufgaben wie .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu halten, bevor sie veröffentlicht werden.

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

Agent.ToolsDirectory Das Verzeichnis, das von Aufgaben wie Node Tool Installer und Use Python Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis PATH hinzu, damit nachfolgende Buildschritte sie verwenden können.

Erfahren Sie mehr über das Verwalten dieses Verzeichnisses auf einem selbst gehosteten Agent.
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Beispiel: c:\agent_work.

Hinweis: Dieses Verzeichnis ist nicht garantiert, dass sie von Pipelineaufgaben (z. B. beim Zugeordneten in einen Container) geschrieben werden kann.

Buildvariablen (DevOps Server 2020)


VariableBESCHREIBUNGIn Vorlagen verfügbar?
Build.ArtifactStagingDirectory

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

Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen" zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, damit Sie es nicht selbst bereinigen müssen.

Siehe Artefakte in Azure-Pipelines.

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.

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

Eine typische Verwendung dieser Variable besteht darin, ihn zum Teil des Bezeichnungsformats zu machen, das Sie auf der Registerkarte "Repository" angeben.

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



Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.

Nein
Build.BuildUri Der URI für den Build. Beispiel: vstfs:///Build/Build/1430.

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

Standardmäßig sind neue Buildpipelinen nicht eingerichtet, um dieses Verzeichnis zu bereinigen. Sie können Ihren Build definieren, um sie auf der Registerkarte "Repository" zu bereinigen.

Beispiel: c:\agent_work\1\b.

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.
Nein
Build.ContainerId Die ID des Containers für Ihr Artefakte. Wenn Sie ein Artefakte in Ihrer Pipeline hochladen, wird es zu einem Container hinzugefügt, der für dieses bestimmte Artefakte 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.Grund Das Ereignis, das dazu führte, dass der Build ausgeführt wird.
  • Manual: Ein Benutzer hat den Build manuell in die Warteschlange gestellt.
  • IndividualCI: Kontinuierliche Integration (CI) ausgelöst durch einen Git-Push oder ein TFVC-Check-In.
  • BatchedCI: Fortlaufende Integration (CI) ausgelöst durch einen Git-Push oder ein TFVC-Check-In, und die Batchänderungen wurden ausgewählt.
  • Schedule: Geplanter Trigger.
  • ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Regalets manuell in die Warteschlange gestellt.
  • CheckInShelveset: Check-In-Trigger für Gitter .
  • PullRequest: Der Build wurde durch eine Git-Verzweigungsrichtlinie ausgelöst, die einen Build erfordert.
  • ResourceTrigger: Der Build wurde durch einen Ressourcenauslöser ausgelöst oder durch einen anderen Build ausgelöst.
Siehe Buildpipeline-Trigger, Verbessern der Codequalität mit Zweigrichtlinien.
Ja
Build.Repository.Clean Der Wert, den Sie für "Bereinigen" in den Quell-Repositoryeinstellungen ausgewählt haben.

Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.
Nein
Build.Repository.LocalPath

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

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

Wichtig 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 unterscheidet sich möglicherweise vom Wert der Build.SourcesDirectory-Variable):

  • Wenn der Auscheckschritt für das Self-Repository (primär) keinen benutzerdefinierten Auscheckpfad definiert hat oder der Auscheckpfad der Standardpfad $(Pipeline.Workspace)/s/<RepoName> für das Self-Repository ist, wird der Wert dieser Variable auf den Standardwert zurückgesetzt.$(Pipeline.Workspace)/s
  • Wenn der Auscheckschritt für das Self-Repository (primär) einen benutzerdefinierten Auscheckpfad definiert hat (und nicht sein Standardpfad für mehrchecken), enthält diese Variable den genauen Pfad zum Self-Repository.
Diese Variable ist agentbereichd und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerungstag.
Nein
Build.Repository.ID Der eindeutige Bezeichner des Repositorys.

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

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

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


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

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.Repository.Uri Die URL für das auslösende Repository. Beispiel: Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Nein
Build.RequestedFor Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.

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

Ja
Build.RequestedForEmail Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt. Ja
Build.RequestedForId Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt. Ja
Build.SourceBranch Der Zweig des auslösenden Repo, für das der Build in die Warteschlange gestellt wurde. Einige Beispiele:
  • Git-Repo-Verzweigung: refs/heads/main
  • Git-Repo-Pullanforderung: refs/pull/1/merge
  • TFVC-Repo-Verzweigung: $/teamproject/main
  • TFVC-Repo-Check-In: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC-Repo-Regale erstellen: myshelveset;username@live.com
  • Wenn Ihre Pipeline durch ein Tag ausgelöst wird: refs/tags/your-tag-name
Wenn Sie diese Variable im Buildnummernformat verwenden, werden die Schrägstrichzeichen (/) durch Unterstriche _ersetzt).

Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.
Ja
Build.SourceBranchName Der Name der Verzweigung im auslösenden Repo, für das der Build in die Warteschlange gestellt wurde.
  • Git-Repo-Verzweigung, Pullanforderung oder Tag: Das letzte Pfadsegment im Bezug. In diesem Wert ist mainz. Brefs/heads/main. . In refs/heads/feature/tools diesem Wert ist tools. In refs/tags/your-tag-name diesem Wert ist your-tag-name.
  • TFVC-Repo-Verzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. In diesem Wert ist mainz. B$/teamproject/main. .
  • TFVC Repo gated Check-In oder Regalet Build ist der Name des Regals. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.
Ja
Build.SourcesDirectory

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

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

Wichtig: Wenn Sie nur ein Git-Repository auschecken, ist dieser Pfad der genaue Pfad zum Code. Wenn Sie mehrere Repositorys auschecken, wird er auf den Standardwert zurückgesetzt, der $(Pipeline.Workspace)/sauch dann ausgecheckt wird, wenn das Selbstrepository auf einen benutzerdefinierten Pfad ausgecheckt wird, der sich von seinem Standardpfad $(Pipeline.Workspace)/s/<RepoName> mit mehreren Auscheckvorgängen unterscheidet (in diesem Zusammenhang unterscheidet sich die Variable vom Verhalten der Variable Build.Repository.LocalPath).

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Nein
Build.SourceVersion Die neueste Versionssteuerungsänderung des auslösenden Repo, das in diesem Build enthalten ist. Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Ja
Build.SourceVersionMessage Der Kommentar des Commits oder des Änderungssets für das auslösende Repo. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen, je nachdem, was kürzer ist.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag. Außerdem ist diese Variable nur auf Schrittebene verfügbar und steht weder in der Auftrags- noch in Phasenebene zur Verfügung (d. h. die Nachricht wird erst extrahiert, wenn der Auftrag gestartet und den Code ausgecheckt hat).

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

Nein
Build.StagingDirectory

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

Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen " zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen.

Siehe Artefakte in Azure-Pipelines.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

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

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.SourceTfvcShelveset Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist.


Wenn Sie einen gated Build oder einen Regalet-Build ausführen, wird dies auf den Namen der Regale festgelegt, die Sie erstellen.

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

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.TriggeredBy.DefinitionId Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildvervollständigen-Trigger ausgelöst.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.TriggeredBy.DefinitionName Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildvervollständigen-Trigger ausgelöst.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.TriggeredBy.BuildNumber Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die Anzahl des auslösenden Builds festgelegt. In klassischen Pipelines wird diese Variable durch einen Buildvervollständigen-Trigger ausgelöst.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Build.TriggeredBy.ProjectID Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die ID des Projekts festgelegt, das den auslösenden Build enthält. In klassischen Pipelines wird diese Variable durch einen Buildvervollständigen-Trigger ausgelöst.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein
Common.TestResultsDirectory Der lokale Pfad für den Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein

Pipelinevariablen (DevOps Server 2020)

VariableBESCHREIBUNG
Pipeline.Workspace Arbeitsbereichsverzeichnis für eine bestimmte Pipeline. Diese Variable hat denselben Wert wie Agent.BuildDirectory.

Beispiel: /home/vsts/work/1.

Bereitstellungsauftragsvariablen (DevOps Server 2020)

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

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

Systemvariablen (DevOps Server 2020)

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 agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Ja
System.CollectionId Die GUID der TFS-Auflistung oder Azure DevOps-Organisation Ja
System.CollectionUri Ein URI der Zeichenfolge Team Foundation Server-Auflistung. Ja
System.DefaultWorkingDirectory

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

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

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Nein
System.DefinitionId Die ID der Buildpipeline. Ja
System.HostType Legen Sie fest build , ob die Pipeline ein Build ist. Für eine Version gelten deployment die Werte für einen Bereitstellungsgruppenauftrag, gates während der Auswertung von Gates und release für andere (Agent- und Agentless)-Aufträge. Ja
System.JobAttempt Legen Sie auf 1 fest, wenn dieser Auftrag zum ersten Mal versucht wird, und erhöht jedes Mal, wenn der Auftrag erneut ausgeführt wird. Nein
System.JobDisplayName Der menschlich lesbare Name, der einem Auftrag zugewiesen 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 in der Regel zum Ausdrücken von Abhängigkeiten und zum Zugriff auf Ausgabevariablen verwendet wird. Nein
System.PhaseAttempt Legen Sie auf 1 fest, wenn diese Phase zum ersten Mal versucht wird, und erhöht jedes Mal, wenn der Auftrag erneut ausgeführt wird.

Hinweis: "Phase" ist ein meist redundantes Konzept, das die Entwurfszeit für einen Auftrag darstellt (während der Auftrag die Laufzeitversion einer Phase war). Wir haben hauptsächlich das Konzept der "Phase" aus Azure-Pipelines entfernt. Matrix- und Multikonfigurationsaufträge sind der einzige Ort, an dem "Phase" immer noch von "Job" unterscheidet. Eine Phase kann mehrere Aufträge instanziieren, die sich nur in ihren Eingaben unterscheiden.
Nein
System.PhaseDisplayName Der menschlich lesbare Name, der einer Phase zugewiesen wird. Nein
System.PhaseName Ein Zeichenfolgen-basierter Bezeichner für einen Auftrag, der in der Regel zum Ausdrucken von Abhängigkeiten und zum Zugriff auf Ausgabevariablen verwendet wird. Nein
System.StageAttempt Legen Sie auf 1 fest, wenn diese Phase zum ersten Mal versucht wird, und erhöht jedes Mal, wenn der Auftrag erneut ausgeführt wird. Nein
System.StageDisplayName Der menschlich lesbare Name, der einer Stufe zugewiesen wird. Nein
System.StageName Ein Zeichenfolgen-basierter Bezeichner für eine Stufe, die in der Regel zum Ausdrucken von Abhängigkeiten und zugriff auf Ausgabevariablen verwendet wird. Ja
System.PullRequest.IsFork Wenn die Pullanforderung von einer Freihandeingabe des Repositorys stammt, wird diese Variable auf Truefestgelegt. Andernfalls ist er auf False. Ja
System.PullRequest.PullRequestId Die ID der Pullanforderung, die diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist). Nein
System.PullRequest.PullRequestNumber Die Anzahl der Pullanforderung, die diesen Build verursacht hat. Diese Variable wird für Pullanforderungen von GitHub ausgefüllt, die eine andere Pull-Anforderungs-ID und Eine Pullanforderungsnummer aufweisen. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Verzweigungsrichtlinie betroffen ist. Nein
System.PullRequest.SourceBranch Die Verzweigung, die in einer Pullanforderung überprüft wird. Beispiel: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist). Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Verzweigungsrichtlinie betroffen ist. Nein
System.PullRequest.SourceRepositoryURI Die URL zum Repository, das die Pullanforderung enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject. Nein
System.PullRequest.TargetBranch Die Verzweigung, die das Ziel einer Pullanforderung ist. Beispiel: refs/heads/main Wenn sich Ihr Repository in Azure Repos befindet und main sich Ihr Repository in GitHub befindet. Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist. Diese Variable ist nur in einer YAML-Pipeline verfügbar, wenn die PR von einer Verzweigungsrichtlinie betroffen ist. Nein
System.TeamFoundationCollectionUri Der URI der Team Foundation-Auflistung. Beispiel: https://dev.azure.com/fabrikamfiber/

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Ja
System.TeamProject Der Name des Projekts, das diesen Build enthält. Ja
System.TeamProjectId Die ID des Projekts, zu dem dieser Build gehört. Ja
TF_BUILD Legen Sie fest True , ob das Skript von einer Buildaufgabe ausgeführt wird.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Nein

Agentvariablen (DevOps Server 2019)

Hinweis

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

VariableBESCHREIBUNG
Agent.BuildDirectory

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

Beispiel: c:\agent_work\1

Agent.HomeDirectory Das Verzeichnis, in dem der Agent installiert ist. Dies enthält die Agentsoftware. Beispiel: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobName Der Name des ausgeführten Auftrags. Dies ist in der Regel "Auftrag" oder "__default", aber in Multi-Config-Szenarien ist die Konfiguration.
Agent.JobStatus Der Status des Builds.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Die Umgebungsvariable sollte als AGENT_JOBSTATUS. Die ältere agent.jobstatus ist zur Abwärtskompatibilität verfügbar.

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

Der Name des Agents, der mit dem Pool registriert ist.

Wenn Sie einen selbst gehosteten Agent verwenden, wird dieser Name von Ihnen angegeben. Weitere Informationen finden Sie unter Agents.

Agent.OS Das Betriebssystem des Agenthosts. Gültige Werte sind:
  • Windows_NT
  • Darwin
  • Linux
Wenn Sie in einem Container ausgeführt werden, kann der Agenthost und der Container verschiedene Betriebssysteme ausführen.
Agent.OSArchitecture Die Betriebssystemprozessorarchitektur des Agenthosts. Gültige Werte sind:
  • X86
  • X64
  • ARM
Agent.TempDirectory Ein temporärer Ordner, der nach jedem Pipelineauftrag bereinigt wird. Dieses Verzeichnis wird von Aufgaben wie .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu halten, bevor sie veröffentlicht werden.
Agent.ToolsDirectory Das Verzeichnis, das von Aufgaben wie Node Tool Installer und Use Python Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis PATH hinzu, damit nachfolgende Buildschritte sie verwenden können.

Erfahren Sie mehr über das Verwalten dieses Verzeichnisses auf einem selbst gehosteten Agent.
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Beispiel: c:\agent_work.

Dieses Verzeichnis ist nicht garantiert, dass sie durch Pipelineaufgaben (z. B. beim Zugeordneten in einen Container) geschrieben werden kann.

Buildvariablen (DevOps Server 2019)


VariableBESCHREIBUNG
Build.ArtifactStagingDirectory

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

Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen" zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, damit Sie es nicht selbst bereinigen müssen.

Siehe Artefakte in Azure-Pipelines.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

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

Eine typische Verwendung dieser Variable besteht darin, ihn zum Teil des Bezeichnungsformats zu machen, das Sie auf der Registerkarte "Repository" angeben.

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



Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Build.BuildUri Der URI für den Build. Beispiel: vstfs:///Build/Build/1430.

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

Standardmäßig sind neue Buildpipelinen nicht eingerichtet, um dieses Verzeichnis zu bereinigen. Sie können Ihren Build definieren, um sie auf der Registerkarte "Repository" zu bereinigen.

Beispiel: c:\agent_work\1\b.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.DefinitionName Der Name der Buildpipeline.

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

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

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

Build.QueuedById Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.Grund Das Ereignis, das dazu führte, dass der Build ausgeführt wird.
  • Manual: Ein Benutzer hat den Build manuell in die Warteschlange gestellt.
  • IndividualCI: Kontinuierliche Integration (CI) ausgelöst durch einen Git-Push oder ein TFVC-Check-In.
  • BatchedCI: Fortlaufende Integration (CI) ausgelöst durch einen Git-Push oder ein TFVC-Check-In, und die Batchänderungen wurden ausgewählt.
  • Schedule: Geplanter Trigger.
  • ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Regalets manuell in die Warteschlange gestellt.
  • CheckInShelveset: Check-In-Trigger für Gitter .
  • PullRequest: Der Build wurde durch eine Git-Verzweigungsrichtlinie ausgelöst, die einen Build erfordert.
  • BuildCompletion: Der Build wurde durch einen anderen Build ausgelöst.
Siehe Buildpipeline-Trigger, Verbessern der Codequalität mit Zweigrichtlinien.
Build.Repository.Clean Der Wert, den Sie für "Bereinigen" in den Quell-Repositoryeinstellungen ausgewählt haben.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.LocalPath

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

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

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Diese Variable ist synonym mit Build.SourcesDirectory.

Build.Repository.Name Der Name des Repositorys.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Provider Der Typ des von Ihnen ausgewählten Repositorys. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Tfvc.Workspace Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Der Name des TFVC-Arbeitsbereichs , der vom Build-Agent verwendet wird.


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

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Uri Die URL für das Repository. Beispiel: Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.RequestedFor Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.

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

Build.RequestedForEmail Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.
Build.RequestedForId Siehe "Wie werden die Identitätsvariablen festgelegt?" angezeigt.
Build.SourceBranch Der Zweig, für den der Build in die Warteschlange gestellt wurde. Einige Beispiele:
  • Git-Repo-Verzweigung: refs/heads/main
  • Git-Repo-Pullanforderung: refs/pull/1/merge
  • TFVC-Repo-Verzweigung: $/teamproject/main
  • TFVC-Repo-Check-In: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC-Repo-Regale erstellen: myshelveset;username@live.com
Wenn Sie diese Variable im Buildnummernformat verwenden, werden die Schrägstrichzeichen (/) durch Unterstriche _ersetzt).

Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.
Build.SourceBranchName Der Name der Verzweigung, für die der Build in die Warteschlange gestellt wurde.
  • Git-Repo-Verzweigung, Pullanforderung oder Tag: Das letzte Pfadsegment im Bezug. In diesem Wert ist mainz. Brefs/heads/main. . In refs/heads/feature/tools diesem Wert ist tools. In refs/tags/your-tag-name diesem Wert ist your-tag-name.
  • TFVC-Repo-Verzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. Beispiel für $/teamproject/main diesen Wert ist main.
  • TFVC Repo gated Check-In oder Regalet Build ist der Name des Regals. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.
Build.SourcesDirectory

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

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

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Diese Variable ist synonym für Build.Repository.LocalPath.

Build.SourceVersion Die neueste Versionssteuerelementänderung, die in diesem Build enthalten ist. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.SourceVersionMessage Der Kommentar des Commit- oder Änderungssets. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen, je nachdem, was kürzer ist.

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

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

Build.StagingDirectory

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

Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen " zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen.

Siehe Artefakte in Azure-Pipelines.

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

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

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.SourceTfvcShelveset Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist.


Wenn Sie einen gated Build oder einen Regalet-Build ausführen, wird dies auf den Namen der Regale festgelegt, die Sie erstellen.

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

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.TriggeredBy.DefinitionId Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die DefinitionID des auslösenden Builds festgelegt.

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.TriggeredBy.DefinitionName Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf den Namen der auslösenden Buildpipeline festgelegt.

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.TriggeredBy.BuildNumber Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die Anzahl des auslösenden Builds festgelegt.

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.TriggeredBy.ProjectID Wenn der Build von einem anderen Build ausgelöst wurde, wird diese Variable auf die ID des Projekts festgelegt, das den auslösenden Build enthält.

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Common.TestResultsDirectory Der lokale Pfad auf dem Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Systemvariablen (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 agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
System.CollectionId Die GUID der TFS-Auflistung oder Azure DevOps-Organisation
System.DefaultWorkingDirectory

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

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

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

System.DefinitionId Die ID der Buildpipeline.
System.HostType Legen Sie fest build , ob die Pipeline ein Build ist. Für eine Version sind deployment die Werte für einen Bereitstellungsgruppenauftrag und release für einen Agent-Auftrag.
System.PullRequest.IsFork Wenn die Pullanforderung von einer Freihand des Repositorys stammt, wird diese Variable auf True"festgelegt" festgelegt. Andernfalls ist er auf False".
System.PullRequest.PullRequestId Die ID der Pullanforderung, die diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist.)
System.PullRequest.PullRequestNumber Die Anzahl der Pull-Anforderung, die diesen Build verursacht hat. Diese Variable wird für Pullanforderungen von GitHub ausgefüllt, die eine andere Pull-Anforderungs-ID und Eine Pull-Anforderungsnummer aufweisen.
System.PullRequest.SourceBranch Die Verzweigung, die in einer Pullanforderung überprüft wird. Beispiel: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist.)
System.PullRequest.SourceRepositoryURI Die URL zum Repo, das die Pullanforderung enthält. Beispiel: https://dev.azure.com/ouraccount/_git/OurProject. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Azure Repos Git PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist. Sie wird für GitHub-PRs nicht initialisiert.)
System.PullRequest.TargetBranch Der Zweig, der das Ziel einer Pullanforderung ist. Beispiel: refs/heads/main. Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Zweigrichtlinie betroffen ist.
System.TeamFoundationCollectionUri Der URI der Team foundation-Auflistung. Beispiel: https://dev.azure.com/fabrikamfiber/.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
System.TeamProject Der Name des Projekts, das diesen Build enthält.
System.TeamProjectId Die ID des Projekts, zu dem dieser Build gehört.
TF_BUILD True Legen Sie fest, ob das Skript von einer Buildaufgabe ausgeführt wird.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Agentvariablen (TFS 2018)

Hinweis

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

VariableBESCHREIBUNG
Agent.BuildDirectory

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

Beispiel: c:\agent_work\1

Agent.HomeDirectory Das Verzeichnis, in das der Agent installiert ist. Dies enthält die Agentsoftware. Beispiel: c:\agent.
Agent.Id Die ID der Momentaufnahme.
Agent.JobStatus Der Status des Builds.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (teilweise erfolgreich)

Die Umgebungsvariable sollte als AGENT_JOBSTATUSreferenziert werden. Die ältere agent.jobstatus ist für die Abwärtskompatibilität verfügbar.

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

Der Name des Agent, der mit dem Pool registriert ist.

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

Agent.TempDirectory Ein temporärer Ordner, der nach jedem Pipelineauftrag bereinigt wird. Dieses Verzeichnis wird von Aufgaben wie .NET Core CLI-Aufgabe verwendet, um temporäre Elemente wie Testergebnisse zu halten, bevor sie veröffentlicht werden.
Agent.ToolsDirectory Das Verzeichnis, das von Aufgaben wie Node Tool Installer und Use Python Version verwendet wird, um zwischen mehreren Versionen eines Tools zu wechseln. Diese Aufgaben fügen Tools aus diesem Verzeichnis PATH hinzu, damit nachfolgende Buildschritte sie verwenden können.

Erfahren Sie mehr über das Verwalten dieses Verzeichnisses auf einem selbst gehosteten Agent.
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent. Beispiel: c:\agent_work.

Buildvariablen (TFS 2018)


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

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

Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen" zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, damit Sie es nicht selbst bereinigen müssen.

Siehe Artefakte in Azure-Pipelines.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

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

Eine typische Verwendung dieser Variable besteht darin, ihn zum Teil des Bezeichnungsformats zu machen, das Sie auf der Registerkarte "Repository" angeben.

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



Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Versionssteuerungstag.

Build.BuildUri Der URI für den Build. Beispiel: vstfs:///Build/Build/1430.

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

Standardmäßig sind neue Buildpipelinen nicht eingerichtet, um dieses Verzeichnis zu bereinigen. Sie können Ihren Build definieren, um sie auf der Registerkarte "Repository" zu bereinigen.

Beispiel: c:\agent_work\1\b.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.DefinitionName Der Name der Buildpipeline.

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

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

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

Build.QueuedById Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.Grund Das Ereignis, das dazu führte, dass der Build ausgeführt wird.
  • Manual: Ein Benutzer hat den Build manuell aus der Benutzeroberfläche oder einen API-Aufruf in die Warteschlange gestellt.
  • IndividualCI: Kontinuierliche Integration (CI) ausgelöst durch einen Git-Push oder ein TFVC-Check-In.
  • BatchedCI: Fortlaufende Integration (CI) ausgelöst durch einen Git-Push oder ein TFVC-Check-In, und die Batchänderungen wurden ausgewählt.
  • Schedule: Geplanter Trigger.
  • ValidateShelveset: Ein Benutzer hat den Build eines bestimmten TFVC-Regalets manuell in die Warteschlange gestellt.
  • CheckInShelveset: Check-In-Trigger für Gitter .
  • PullRequest: Der Build wurde durch eine Git-Verzweigungsrichtlinie ausgelöst, die einen Build erfordert.
Siehe Buildpipeline-Trigger, Verbessern der Codequalität mit Zweigrichtlinien.
Build.Repository.Clean Der Wert, den Sie für "Bereinigen" in den Quell-Repositoryeinstellungen ausgewählt haben.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.LocalPath

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

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

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Diese Variable ist synonym mit Build.SourcesDirectory.

Build.Repository.Name Der Name des Repositorys.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Provider Der Typ des von Ihnen ausgewählten Repositorys. Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Tfvc.Workspace Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist. Der Name des TFVC-Arbeitsbereichs , der vom Build-Agent verwendet wird.

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

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.Repository.Uri Die URL für das Repository. Beispiel:
  • Git: https://fabrikamfiber/tfs/DefaultCollection/Scripts/_git/Scripts
  • TFVC: https://fabrikamfiber/tfs/DefaultCollection/
Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.RequestedFor Siehe "Wie werden die Identitätsvariablen festgelegt?".

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

Build.RequestedForEmail Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.RequestedForId Siehe "Wie werden die Identitätsvariablen festgelegt?".
Build.SourceBranch Der Zweig, für den der Build in die Warteschlange gestellt wurde. Einige Beispiele:
  • Git-Repo-Verzweigung: refs/heads/main
  • Git-Repo-Pullanforderung: refs/pull/1/merge
  • TFVC-Repo-Verzweigung: $/teamproject/main
  • TFVC-Repo-Check-In: Gated_2016-06-06_05.20.51.4369;username@live.com
  • TFVC-Repo-Regale erstellen: myshelveset;username@live.com
Wenn Sie diese Variable im Buildnummernformat verwenden, werden die Schrägstrichzeichen (/) durch Unterstriche _ersetzt).

Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.
Build.SourceBranchName Der Name der Verzweigung, für die der Build in die Warteschlange gestellt wurde.
  • Git-Repo-Verzweigung, Pullanforderung oder Tag: Das letzte Pfadsegment im Bezug. In diesem Wert ist mainz. Brefs/heads/main. . In refs/heads/feature/tools diesem Wert ist tools.
  • TFVC-Repo-Verzweigung: Das letzte Pfadsegment im Stammserverpfad für den Arbeitsbereich. Beispiel für $/teamproject/main diesen Wert ist main. In refs/tags/your-tag-name diesem Wert ist your-tag-name.
  • TFVC Repo gated Check-In oder Regalet Build ist der Name des Regals. Zum Beispiel: Gated_2016-06-06_05.20.51.4369;username@live.com oder myshelveset;username@live.com.
Hinweis: Bei TFVC können Sie diese Variable nicht im Buildformat der Buildnummer verwenden, wenn Sie einen gated Check-In-Build ausführen oder manuell ein Regalset erstellen.
Build.SourcesDirectory

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

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

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Diese Variable ist synonym für Build.Repository.LocalPath.

Build.SourceVersion Die neueste Versionssteuerelementänderung, die in diesem Build enthalten ist. Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.SourceVersionMessage Der Kommentar des Commit- oder Änderungssets. Wir kürzen die Nachricht auf die erste Zeile oder 200 Zeichen, je nachdem, was kürzer ist.

Diese Variable ist agent-scoped und kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

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

Build.StagingDirectory

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

Eine typische Möglichkeit zum Verwenden dieses Ordners besteht darin, Ihre Buildartefakte mit den Aufgaben " Dateien kopieren " und " Buildartefakte veröffentlichen " zu veröffentlichen.

Hinweis: Build.ArtifactStagingDirectory und Build.StagingDirectory sind austauschbar. Dieses Verzeichnis wird vor jedem neuen Build gelöscht, sodass Sie es nicht selbst bereinigen müssen.

Siehe Artefakte in Azure-Pipelines.

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

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

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
Build.SourceTfvcShelveset Definiert, wenn Ihr Repository Team Foundation-Versionskontrolle ist.

Wenn Sie einen gated Build oder einen Regalet-Build ausführen, wird dies auf den Namen der Regale festgelegt, die Sie erstellen.

Hinweis: Diese Variable gibt einen Wert zurück, der für die Buildverwendung in einem Buildnummernformat ungültig ist.
Common.TestResultsDirectory Der lokale Pfad für den Agent, in dem die Testergebnisse erstellt werden. Beispiel: c:\agent_work\1\TestResults

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Systemvariablen (TFS 2018)

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

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
System.CollectionId Die GUID der TFS-Auflistung oder Azure DevOps-Organisation
System.DefaultWorkingDirectory

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

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

Diese Variable ist agent-scoped. Sie kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

System.DefinitionId Die ID der Buildpipeline.
System.HostType Legen Sie fest build , ob es sich bei der Pipeline um einen Build handelt oder release ob es sich bei der Pipeline um eine Version handelt.
System.PullRequest.IsFork Wenn die Pullanforderung von einer Freihandeingabe des Repositorys stammt, wird diese Variable auf Truefestgelegt. Andernfalls ist er auf False. Verfügbar in TFS 2018.2.
System.PullRequest.PullRequestId Die ID der Pullanforderung, die diesen Build verursacht hat. Beispiel: 17. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist.)
System.PullRequest.SourceBranch Die Verzweigung, die in einer Pullanforderung überprüft wird. Beispiel: refs/heads/users/raisa/new-feature. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist.)
System.PullRequest.SourceRepositoryURI Die URL zum Repository, das die Pullanforderung enthält. Beispiel: http://our-server:8080/tfs/DefaultCollection/_git/OurProject. (Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Azure Repos Git PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist.)
System.PullRequest.TargetBranch Die Verzweigung, die das Ziel einer Pullanforderung ist. Beispiel: refs/heads/main. Diese Variable wird nur initialisiert, wenn der Build aufgrund einer Git-PR ausgeführt wurde, die von einer Verzweigungsrichtlinie betroffen ist.
System.TeamFoundationCollectionUri Der URI der Team foundation-Auflistung. Beispiel: http://our-server:8080/tfs/DefaultCollection/.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.
System.TeamProject Der Name des Projekts, das diesen Build enthält.
System.TeamProjectId Die ID des Projekts, zu dem dieser Build gehört.
TF_BUILD True Legen Sie fest, ob das Skript von einer Buildaufgabe ausgeführt wird.

Diese Variable ist agent-scoped. Es kann als Umgebungsvariable in einem Skript und als Parameter in einer Buildaufgabe verwendet werden, aber nicht als Teil der Buildnummer oder als Versionssteuerelementtag.

Wie werden die Identitätsvariablen festgelegt?

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

Wenn der Build ausgelöst wird... Anschließend basieren die Werte Build.QueuedBy und Build.QueuedById auf... Anschließend basieren die Werte Build.RequestedForFor und Build.RequestedForId auf...
In Git oder TFVC durch die Fortlaufende Integration (CI)-Trigger Die Systemidentität, z. B.: [DefaultCollection]\Project Collection Service Accounts Die Person, die die Änderungen verschoben oder eingecheckt hat.
In Git oder durch einen Zweigrichtlinien-Build. Die Systemidentität, z. B.: [DefaultCollection]\Project Collection Service Accounts Die Person, die sich in die Änderungen eingecheckt hat.
In TFVC durch einen gegateten Check-In-Trigger Die Person, die sich in die Änderungen eingecheckt hat. Die Person, die sich in die Änderungen eingecheckt hat.
In Git oder TFVC durch die geplanten Trigger Die Systemidentität, z. B.: [DefaultCollection]\Project Collection Service Accounts Die Systemidentität, z. B.: [DefaultCollection]\Project Collection Service Accounts
Da Sie auf die Schaltfläche " Warteschlange erstellen " geklickt haben Sie Sie