Klassische Release- und Artefaktevariablen

Azure DevOps Services | Azure DevOps Server 2022 - 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.

Klassische Release- und Artefaktevariablen sind eine bequeme Möglichkeit, Daten in Ihrer Pipeline auszutauschen und zu transportieren. Jede Variable wird als Zeichenfolge gespeichert, und ihr Wert kann sich zwischen den Ausführungsläufen Ihrer Pipeline ändern.

Variablen unterscheiden sich von Laufzeitparametern , die nur zur Vorlagenanalysezeit verfügbar sind.

Hinweis

Dies ist ein Referenzartikel, der die klassischen Release- und Artefaktevariablen behandelt. Informationen zu Variablen in YAML-Pipelines finden Sie unter benutzerdefinierte Variablen. Wenn Sie von einer Releasepipeline zu einer YAML-Pipeline migrieren, werden die Release.* Variablen nicht ausgefüllt.

Während Sie die Aufgaben für die Bereitstellung Ihrer Anwendung in jeder Phase in Ihren DevOps CI/CD-Prozessen verfassen, helfen Variablen Ihnen:

  • Definieren Sie eine generischere Bereitstellungspipeline einmal, und passen Sie sie dann einfach für jede Phase an. Beispielsweise kann eine Variable verwendet werden, um die Verbindungszeichenfolge für die Webbereitstellung darzustellen, und der Wert dieser Variable kann von einer Phase in eine andere geändert werden. Dies sind benutzerdefinierte Variablen.

  • Verwenden Sie Informationen zum Kontext der bestimmten Version, Phase, Artefakte oder Agent , in der die Bereitstellungspipeline ausgeführt wird. Ihr Skript muss z. B. auf den Speicherort des Builds zugreifen, um ihn herunterzuladen, oder auf das Arbeitsverzeichnis im Agent, um temporäre Dateien zu erstellen. Dies sind Standardvariablen.

Tipp

Sie können die aktuellen Werte aller Variablen für eine Version anzeigen und eine Standardvariable verwenden, um eine Version im Debugmodus auszuführen.

Standardvariablen

Informationen zum Ausführungskontext werden für die Ausführung von Aufgaben über Standardvariablen zur Verfügung gestellt. Ihre Aufgaben und Skripts können diese Variablen verwenden, um Informationen über das System, die Version, die Phase oder den Agent zu finden, in dem sie ausgeführt werden. Mit Ausnahme von System.Debug sind diese Variablen schreibgeschützt, und ihre Werte werden automatisch vom System festgelegt. Einige der wichtigsten Variablen werden in den folgenden Tabellen beschrieben. Informationen zum Anzeigen der vollständigen Liste finden Sie unter Anzeigen der aktuellen Werte aller Variablen.

System

Variablenname BESCHREIBUNG
System.TeamFoundationServerUri Die URL der Dienstverbindung in TFS- oder Azure-Pipelines. Verwenden Sie dies aus Ihren Skripts oder Aufgaben, um REST-APIs von Azure Pipelines aufzurufen.

Ein Beispiel: https://fabrikam.vsrm.visualstudio.com/
System.TeamFoundationCollectionUri Die URL der Team Foundation-Auflistung oder Azure-Pipelines. Verwenden Sie dies aus Ihren Skripts oder Aufgaben, um REST-APIs für andere Dienste wie Build- und Versionssteuerelement aufzurufen.

Ein Beispiel: https://dev.azure.com/fabrikam/
System.CollectionId Die ID der Auflistung, zu der dieser Build oder diese Version gehört. In TFS 2015 nicht verfügbar.

Ein Beispiel: 6c6f3423-1c84-4625-995a-f7f143a1e43d
System.DefinitionId Die ID der Releasepipeline, zu der die aktuelle Version gehört. In TFS 2015 nicht verfügbar.

Ein Beispiel: 1
System.TeamProject Der Name des Projekts, zu dem dieser Build oder diese Version gehört.

Ein Beispiel: Fabrikam
System.TeamProjectId Die ID des Projekts, zu dem dieser Build oder diese Version gehört. In TFS 2015 nicht verfügbar.

Ein Beispiel: 79f5c12e-3337-4151-be41-a268d2c73344
System.ArtifactsDirectory Das Verzeichnis, in das Artefakte während der Bereitstellung einer Version heruntergeladen werden. Das Verzeichnis wird vor jeder Bereitstellung gelöscht, wenn Artefakte auf den Agent heruntergeladen werden müssen. Identisch mit Agent.ReleaseDirectory und System.DefaultWorkingDirectory.

Ein Beispiel: C:\agent\_work\r1\a
System.DefaultWorkingDirectory Das Verzeichnis, in das Artefakte während der Bereitstellung einer Version heruntergeladen werden. Das Verzeichnis wird vor jeder Bereitstellung gelöscht, wenn Artefakte auf den Agent heruntergeladen werden müssen. Identisch mit Agent.ReleaseDirectory und System.ArtifactsDirectory.

Ein Beispiel: C:\agent\_work\r1\a
System.WorkFolder Das Arbeitsverzeichnis für diesen Agent, in dem Unterordner für jeden Build oder jede Version erstellt werden. Identisch mit Agent.RootDirectory und Agent.WorkFolder.

Ein Beispiel: C:\agent\_work
System.Debug Dies ist die einzige Systemvariable, die von den Benutzern festgelegt werden kann. Legen Sie dies auf "true" fest, um die Version im Debugmodus auszuführen, um fehlersuche zu unterstützen.

Ein Beispiel: true

Release

Variablenname BESCHREIBUNG
Release.AttemptNumber Die Anzahl der Bereitstellungen dieser Version in dieser Phase. In TFS 2015 nicht verfügbar.

Ein Beispiel: 1
Release.DefinitionEnvironmentId Die ID der Stufe in der entsprechenden Releasepipeline. In TFS 2015 nicht verfügbar.

Ein Beispiel: 1
Release.DefinitionId Die ID der Releasepipeline, zu der die aktuelle Version gehört. In TFS 2015 nicht verfügbar.

Ein Beispiel: 1
Release.DefinitionName Der Name der Releasepipeline, zu der das aktuelle Release gehört.

Ein Beispiel: fabrikam-cd
Release.Deployment.RequestedFor Der Anzeigename der Identität, die die Derzeit ausgeführte Bereitstellung ausgelöst (gestartet) hat. In TFS 2015 nicht verfügbar.

Ein Beispiel: Mateo Escobedo
Release.Deployment.RequestedForEmail Die E-Mail-Adresse der Identität, die die Bereitstellung ausgelöst (gestartet) hat, die derzeit ausgeführt wird. In TFS 2015 nicht verfügbar.

Ein Beispiel: mateo@fabrikam.com
Release.Deployment.RequestedForId Die ID der Identität, die die Bereitstellung ausgelöst hat (gestartet), die derzeit ausgeführt wird. In TFS 2015 nicht verfügbar.

Ein Beispiel: 2f435d07-769f-4e46-849d-10d1ab9ba6ab
Release.DeploymentID Die ID der Bereitstellung. Eindeutig pro Auftrag.

Ein Beispiel: 254
Release.DeployPhaseID Die ID der Phase, in der die Bereitstellung ausgeführt wird.

Ein Beispiel: 127
Release.EnvironmentId Die ID der Phaseninstanz in einer Version, für die die Bereitstellung derzeit ausgeführt wird.

Ein Beispiel: 276
Release.EnvironmentName Der Name der Phase, für die die Bereitstellung derzeit ausgeführt wird.

Ein Beispiel: Dev
Release.EnvironmentUri Der URI der Phaseninstanz in einer Version, in der die Bereitstellung derzeit ausgeführt wird.

Ein Beispiel: vstfs://ReleaseManagement/Environment/276
Release.Environments. {Stage-name}.status Der Bereitstellungsstatus der Phase.

Ein Beispiel: InProgress
Release.PrimaryArtifactSourceAlias Der Alias der primären Artefaktequelle

Ein Beispiel: fabrikam\_web
Release.Grund Der Grund für die Bereitstellung. Diese Werte werden unterstützt:
ContinuousIntegration - die Version begann in der fortlaufenden Bereitstellung nach Abschluss eines Builds.
Manual - Die Version wurde manuell gestartet.
None - der Bereitstellungsgrund wurde nicht angegeben.
Schedule - die Veröffentlichung wurde aus einem Zeitplan gestartet.
Release.ReleaseDescription Die Textbeschreibung, die zur Zeit der Veröffentlichung bereitgestellt wird.

Ein Beispiel: Critical security patch
Release.ReleaseId Der Bezeichner des aktuellen Releasedatensatzs.

Ein Beispiel: 118
Release.ReleaseName Der Name der aktuellen Version.

Ein Beispiel: Release-47
Release.ReleaseUri Der URI der aktuellen Version.

Ein Beispiel: vstfs://ReleaseManagement/Release/118
ReleaseWebURL Die URL für diese Version.

Ein Beispiel: https://dev.azure.com/fabrikam/f3325c6c/_release?releaseId=392&_a=release-summary
Release.RequestedForFor Der Anzeigename der Identität, die die Version ausgelöst hat.

Ein Beispiel: Mateo Escobedo
Release.RequestedForEmail Die E-Mail-Adresse der Identität, die die Version ausgelöst hat.

Ein Beispiel: mateo@fabrikam.com
Release.RequestedForId Die ID der Identität, die die Version ausgelöst hat.

Ein Beispiel: 2f435d07-769f-4e46-849d-10d1ab9ba6ab
Release.SkipArtifactsDownload Boolescher Wert, der angibt, ob das Herunterladen von Artefakten in den Agent übersprungen werden soll.

Ein Beispiel: FALSE
Release.TriggeringArtifact.Alias Der Alias des Artefaktes, der die Veröffentlichung ausgelöst hat. Dies ist leer, wenn die Version geplant oder manuell ausgelöst wurde.

Ein Beispiel: fabrikam\_app

Release-Phase

Variablenname BESCHREIBUNG
Release.Environments. {Phasenname}. Status Der Status der Bereitstellung dieser Version in einer angegebenen Phase. In TFS 2015 nicht verfügbar.

Ein Beispiel: NotStarted

Agent

Variablenname BESCHREIBUNG
Agent.Name Der Name des Agent als registriert mit dem Agentpool. Dies unterscheidet sich wahrscheinlich von dem Computernamen.

Ein Beispiel: fabrikam-agent
Agent.MachineName Der Name des Computers, auf dem der Agent konfiguriert ist.

Ein Beispiel: fabrikam-agent
Agent.Version Die Version der Agentsoftware.

Ein Beispiel: 2.109.1
Agent.JobName Der Name des Auftrags, der ausgeführt wird, z. B. Release oder Build.

Ein Beispiel: Release
Agent.HomeDirectory Der Ordner, in dem der Agent installiert ist. Dieser Ordner enthält den Code und die Ressourcen für den Agent.

Ein Beispiel: C:\agent
Agent.ReleaseDirectory Das Verzeichnis, in das Artefakte während der Bereitstellung einer Version heruntergeladen werden. Das Verzeichnis wird vor jeder Bereitstellung gelöscht, wenn Artefakte auf den Agent heruntergeladen werden müssen. Identisch mit System.ArtifactsDirectory und System.DefaultWorkingDirectory.

Ein Beispiel: C:\agent\_work\r1\a
Agent.RootDirectory Das Arbeitsverzeichnis für diesen Agent, in dem Unterordner für jeden Build oder jede Version erstellt werden. Identisch mit Agent.WorkFolder und System.WorkFolder.

Ein Beispiel: C:\agent\_work
Agent.WorkFolder Das Arbeitsverzeichnis für diesen Agent, in dem Unterordner für jeden Build oder jede Version erstellt werden. Identisch mit Agent.RootDirectory und System.WorkFolder.

Ein Beispiel: C:\agent\_work
Agent.DeploymentGroupId Die ID der Bereitstellungsgruppe, mit der der Agent registriert ist. Dies ist nur in Bereitstellungsgruppenaufträgen verfügbar. In TFS 2018 Update 1 ist nicht verfügbar.

Ein Beispiel: 1

Allgemeines Artefakte

Für jedes Artefakte, auf das in einer Version verwiesen wird, können Sie die folgenden Artefaktevariablen verwenden. Nicht alle Variablen sind für jeden Artefakttyp sinnvoll. In der folgenden Tabelle sind die Standardartefaktevariablen aufgeführt und beispiele für die Werte aufgeführt, die sie je nach Artefakttyp haben. Wenn ein Beispiel leer ist, bedeutet dies, dass die Variable für diesen Artefakttyp nicht gefüllt ist.

Ersetzen Sie den {alias} Platzhalter durch den wert, den Sie für den Artefakte alias oder durch den standardwert, der für die Releasepipeline generiert wurde.

Variablenname BESCHREIBUNG
Release.Artefakte. {alias}. DefinitionId Der Bezeichner der Buildpipeline oder des Repositorys.

Beispiel für Azure-Pipelines: 1
GitHub-Beispiel: fabrikam/asp
Release.Artefakte. {alias}. DefinitionName Der Name der Buildpipeline oder des Repositorys.

Beispiel für Azure-Pipelines: fabrikam-ci
TFVC-Beispiel: $/fabrikam
Git-Beispiel: fabrikam
GitHub-Beispiel: fabrikam/asp (main)
Release.Artefakte. {alias}. Buildnumber Die Buildnummer oder der Commit-Bezeichner.

Beispiel für Azure-Pipelines: 20170112.1
Jenkins/TeamCity-Beispiel: 20170112.1
TFVC-Beispiel: Changeset 3
Git-Beispiel: 38629c964
GitHub-Beispiel: 38629c964
Release.Artefakte. {alias}. BuildId Der Buildbezeichner.

Beispiel für Azure-Pipelines: 130
Jenkins/TeamCity-Beispiel: 130
GitHub-Beispiel: 38629c964d21fe405ef830b7d0220966b82c9e11
Release.Artefakte. {alias}. BuildURI Die URL für den Build.

Beispiel für Azure-Pipelines: vstfs://build-release/Build/130
GitHub-Beispiel: https://github.com/fabrikam/asp
Release.Artefakte. {alias}. SourceBranch Der vollständige Pfad und der Name des Zweigs, aus dem die Quelle erstellt wurde.

Beispiel für Azure-Pipelines: refs/heads/main
Release.Artefakte. {alias}. SourceBranchName Der Name nur der Verzweigung, aus der die Quelle erstellt wurde.

Beispiel für Azure-Pipelines: main
Release.Artefakte. {alias}. Sourceversion Der Commit, der erstellt wurde.

Beispiel für Azure-Pipelines: bc0044458ba1d9298cdc649cb5dcf013180706f7
Release.Artefakte. {alias}. Repository.Provider Der Typ des Repositorys, aus dem die Quelle erstellt wurde.

Beispiel für Azure-Pipelines: Git
Release.Artefakte. {alias}. RequestedForID Der Bezeichner des Kontos, das den Build ausgelöst hat.

Beispiel für Azure-Pipelines: 2f435d07-769f-4e46-849d-10d1ab9ba6ab
Release.Artefakte. {alias}. Angefordert Für Der Name des Kontos, das den Build angefordert hat.

Beispiel für Azure-Pipelines: Mateo Escobedo
Release.Artefakte. {alias}. Typ Der Art der Artefaktequelle, z. B. Build.

Beispiel für Azure-Pipelines: Build
Jenkins Beispiel: Jenkins
TeamCity-Beispiel: TeamCity
TFVC-Beispiel: TFVC
Git-Beispiel: Git
GitHub-Beispiel: GitHub
Release.Artefakte. {alias}. PullRequest.TargetBranch Der vollständige Pfad und der Name der Verzweigung, die das Ziel einer Pullanforderung ist. Diese Variable wird nur initialisiert, wenn die Version durch einen Pull-Anforderungsfluss ausgelöst wird.

Beispiel für Azure-Pipelines: refs/heads/main
Release.Artefakte. {alias}. PullRequest.TargetBranchName Der Name nur der Verzweigung, die das Ziel einer Pullanforderung ist. Diese Variable wird nur initialisiert, wenn die Version durch einen Pull-Anforderungsfluss ausgelöst wird.

Beispiel für Azure-Pipelines: main

Siehe auch Artefaktquelle-Alias

Primäres Artefakte

Sie legen einen der Artefakte als primäres Artefakte in einer Releasepipeline fest. Für das angegebene primäre Artefakte füllt Azure Pipelines die folgenden Variablen auf.

Variablenname Identisch mit
Build.DefinitionId Release.Artefakte. {Primärer Artefakte alias}. DefinitionId
Build.DefinitionName Release.Artefakte. {Primärer Artefakte alias}. DefinitionName
Build.BuildNumber Release.Artefakte. {Primärer Artefakte alias}. Buildnumber
Build.BuildId Release.Artefakte. {Primärer Artefakte alias}. BuildId
Build.BuildURI Release.Artefakte. {Primärer Artefakte alias}. BuildURI
Build.SourceBranch Release.Artefakte. {Primärer Artefakte alias}. SourceBranch
Build.SourceBranchName Release.Artefakte. {Primärer Artefakte alias}. SourceBranchName
Build.SourceVersion Release.Artefakte. {Primärer Artefakte alias}. Sourceversion
Build.Repository.Provider Release.Artefakte. {Primärer Artefakte alias}. Repository.Provider
Build.RequestedForID Release.Artefakte. {Primärer Artefakte alias}. RequestedForID
Build.RequestedFor Release.Artefakte. {Primärer Artefakte alias}. Angefordert Für
Build.Type Release.Artefakte. {Primärer Artefakte alias}. Typ
Build.PullRequest.TargetBranch Release.Artefakte. {Primärer Artefakte alias}. PullRequest.TargetBranch
Build.PullRequest.TargetBranchName Release.Artefakte. {Primärer Artefakte alias}. PullRequest.TargetBranchName

Verwenden von Standardvariablen

Sie können die Standardvariablen auf zwei Arten verwenden – als Parameter für Vorgänge in einer Releasepipeline oder in Ihren Skripts.

Sie können eine Standardvariable direkt als Eingabe für eine Aufgabe verwenden. Wenn Sie beispielsweise an die Artefaktequelle übergeben Release.Artifacts.{Artifact alias}.DefinitionName möchten, deren Alias an eine Aufgabe ASPNET4.CI ist, würden Sie verwenden $(Release.Artifacts.ASPNET4.CI.DefinitionName).

Verwenden von Artefaktevariablen in Argumenten zu einer PowerShell-Skriptaufgabe

Um eine Standardvariable in Ihrem Skript zu verwenden, müssen Sie zuerst die . standardvariablen Namen durch _. Um beispielsweise den Wert der Artefaktevariablen Release.Artifacts.{Artifact alias}.DefinitionName für die Artefaktequelle zu drucken, deren Alias ASPNET4.CI in einem PowerShell-Skript ist, würden Sie verwenden $env:RELEASE_ARTIFACTS_ASPNET4_CI_DEFINITIONNAME.

Verwenden von Artefaktevariablen in einem Inline-PowerShell-Skript

Beachten Sie, dass der ursprüngliche Name des Artefaktequelle-Aliass ASPNET4.CIersetzt ASPNET4_CIwird.

Anzeigen der aktuellen Werte aller Variablen

  1. Öffnen Sie die Pipelinesansicht der Zusammenfassung für die Version, und wählen Sie die gewünschte Phase aus. Wählen Sie in der Liste der Schritte den Initialisierungsauftrag aus.

    Öffnen des Protokolls für eine Version

  2. Dadurch wird das Protokoll für diesen Schritt geöffnet. Scrollen Sie nach unten, um die Werte anzuzeigen, die vom Agent für diesen Auftrag verwendet werden.

    Anzeigen der Werte der Variablen in einer Version

Ausführen eines Releases im Debugmodus

Zeigen Sie zusätzliche Informationen als Version ausgeführt und in den Protokolldateien an, indem Sie die gesamte Version ausführen oder nur die Aufgaben in einer einzelnen Releasephase im Debugmodus ausführen. Dadurch können Sie Probleme und Fehler beheben.

  • Um den Debugmodus für eine gesamte Version zu initiieren, fügen Sie eine Variable mit dem Namen true "Variablen" der Registerkarte "VariablenSystem.Debug" einer Releasepipeline hinzu.

  • Um den Debugmodus für eine einzelne Stufe zu initiieren, öffnen Sie das Dialogfeld "Phase konfigurieren" im Kontextmenü der Stufe, und fügen Sie eine Variable mit dem Namen true "Wert" zur Registerkarte "VariablenSystem.Debug" hinzu.

  • Erstellen Sie alternativ eine Variable, die eine Variable mit dem Wert true enthält, und verknüpfen Sie diese Variablengruppe System.Debug mit einer Releasepipeline.

Tipp

Wenn Sie einen Fehler im Zusammenhang mit einer Azure RM-Dienstverbindung erhalten, finden Sie unter How to: Problembehandlung bei Azure Resource Manager-Dienstverbindungen.

Benutzerdefinierte Variablen

Benutzerdefinierte Variablen können in verschiedenen Bereichen definiert werden.

  • Freigeben von Werten über alle Definitionen in einem Projekt mithilfe variabler Gruppen. Wählen Sie eine Variable Gruppe aus, wenn Sie die gleichen Werte in allen Definitionen, Phasen und Vorgängen in einem Projekt verwenden müssen, und Sie möchten die Werte an einem einzigen Ort ändern können. Sie definieren und verwalten variable Gruppen auf der Registerkarte "Bibliothek ".

  • Freigeben von Werten in allen Phasen mithilfe von Releasepipelinevariablen. Wählen Sie eine Releasepipelinevariable aus, wenn Sie denselben Wert in allen Phasen und Aufgaben in der Releasepipeline verwenden müssen, und Sie möchten den Wert an einem einzigen Ort ändern können. Sie definieren und verwalten diese Variablen auf der Registerkarte "Variablen " in einer Releasepipeline. Öffnen Sie auf der Seite "Pipelinevariablen" die Dropdownliste "Bereich", und wählen Sie "Release" aus. Wenn Sie eine Variable hinzufügen, wird standardmäßig der Bereich "Release" festgelegt.

  • Freigeben von Werten in allen Vorgängen innerhalb einer bestimmten Phase mithilfe von Phasenvariablen. Verwenden Sie eine Stufenebenenvariable für Werte, die von Stufe zu Stufe variieren (und sind für alle Aufgaben in einer Phase identisch). Sie definieren und verwalten diese Variablen auf der Registerkarte "Variablen " einer Releasepipeline. Öffnen Sie auf der Seite "Pipelinevariablen" die Dropdownliste "Bereich", und wählen Sie die erforderliche Phase aus. Wenn Sie eine Variable hinzufügen, legen Sie den Bereich auf die entsprechende Umgebung fest.

Die Verwendung benutzerdefinierter Variablen im Projekt, der Releasepipeline und des Phasenbereichs hilft Ihnen:

  • Vermeiden Sie die Duplizierung von Werten, wodurch es einfacher ist, alle Vorkommen als einen Vorgang zu aktualisieren.

  • Speichern sie vertrauliche Werte so, dass sie von Benutzern der Releasepipeline nicht angezeigt oder geändert werden können. Legen Sie eine Konfigurationseigenschaft fest, die eine sichere (geheime) Variable sein soll, indem Sie neben der Variable das Symbol " Padlock ) auswählen.

    Wichtig

    Die Werte der ausgeblendeten (geheimen) Variablen werden sicher auf dem Server gespeichert und können nach dem Speichern von Benutzern nicht angezeigt werden. Während einer Bereitstellung entschlüsselt der Azure-Pipelines-Releasedienst diese Werte beim Verweis auf die Aufgaben und übergibt sie an den Agent über einen sicheren HTTPS-Kanal.

Hinweis

Das Erstellen benutzerdefinierter Variablen kann Standardvariablen überschreiben. Beispielsweise die PowerShell Path-Umgebungsvariable. Wenn Sie eine benutzerdefinierte Path Variable auf einem Windows-Agent erstellen, wird die $env:Path Variable überschrieben, und PowerShell kann nicht ausgeführt werden.

Verwenden von benutzerdefinierten Variablen

Um benutzerdefinierte Variablen in Ihren Build- und Releaseaufgaben zu verwenden, schließen Sie einfach den Variablennamen in Klammern ein, und stellen Sie es mit einem $ Zeichen voraus. Wenn Sie beispielsweise eine Variable mit dem Namen adminUserName haben, können Sie den aktuellen Wert dieser Variable in einen Parameter eines Vorgangs einfügen als $(adminUserName).

Hinweis

Variablen in verschiedenen Gruppen, die mit einer Pipeline in demselben Bereich verknüpft sind (z. B. Auftrag oder Stufe), werden kollidiert, und das Ergebnis kann unvorhersehbar sein. Stellen Sie sicher, dass Sie verschiedene Namen für Variablen in allen Variablengruppen verwenden.

Definieren und Ändern ihrer Variablen in einem Skript

Um eine Variable aus einem Skript zu definieren oder zu ändern, verwenden Sie den task.setvariable Protokollierungsbefehl. Beachten Sie, dass der aktualisierte Variablenwert auf den ausgeführten Auftrag ausgerichtet ist und nicht über Aufträge oder Phasen hinweg fließt. Variablennamen werden in Großbuchstaben transformiert, und die Zeichen "." und " " werden durch "_" ersetzt.

Agent.WorkFolder wird beispielsweise zu AGENT_WORKFOLDER. Unter Windows greifen Sie auf dies als %AGENT_WORKFOLDER% oder $env:AGENT_WORKFOLDER. Auf Linux und macOS verwenden $AGENT_WORKFOLDERSie .

Tipp

Sie können ein Skript auf einer:

Batchskript

Festlegen der sauce Variablen secret.Sauce

@echo ##vso[task.setvariable variable=sauce]crushed tomatoes
@echo ##vso[task.setvariable variable=secret.Sauce;issecret=true]crushed tomatoes with garlic

Lesen der Variablen

Argumente

"$(sauce)" "$(secret.Sauce)"

Skript

@echo off
set sauceArgument=%~1
set secretSauceArgument=%~2
@echo No problem reading %sauceArgument% or %SAUCE%
@echo But I cannot read %SECRET_SAUCE%
@echo But I can read %secretSauceArgument% (but the log is redacted so I do not spoil
     the secret)

Konsolenausgabe aus dem Lesen der Variablen:

No problem reading crushed tomatoes or crushed tomatoes
But I cannot read 
But I can read ******** (but the log is redacted so I do not spoil the secret)