Klassische Release- und Artefaktvariablen

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

Hinweis

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

Klassische Release- und Artefaktvariablen sind eine praktische Möglichkeit zum Austauschen und Transport von Daten in ihrer gesamten Pipeline. Jede Variable wird als Zeichenfolge gespeichert, und ihr Wert kann sich zwischen den Ausführungen Ihrer Pipeline ändern.

Variablen unterscheiden sich von Laufzeitparametern, die nur zum Zeitpunkt der Vorlagenparsierung verfügbar sind.

Hinweis

Dies ist ein Referenzartikel, der die klassischen Release- und Artefaktvariablen 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 aufgefüllt.

Wenn Sie die Aufgaben für die Bereitstellung Ihrer Anwendung in jeder Phase in Ihren DevOps CI/CD-Prozessen zusammenstellen, helfen Ihnen Variablen bei folgenden Aufgaben:

  • Definieren Sie einmal eine allgemeinere Bereitstellungspipeline, 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 Variablen kann von einer Phase in eine andere geändert werden. Dies sind benutzerdefinierte Variablen.

  • Verwenden Sie Informationen zum Kontext des jeweiligen Release, der Phase,der Artefakteoder des Agents, in dem die Bereitstellungspipeline ausgeführt wird. Beispielsweise benötigt Ihr Skript möglicherweise Zugriff auf den Speicherort des Builds, um ihn herunterzuladen, oder auf das Arbeitsverzeichnis auf dem Agent, um temporäre Dateien zu erstellen. Dies sind Standardvariablen.

Tipp

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

Standardvariablen

Informationen zum Ausführungskontext werden ausgeführten Tasks über Standardvariablen zur Verfügung gestellt. Ihre Tasks und Skripts können diese Variablen verwenden, um Informationen zum System, release, stage oder Agent zu finden, in dem sie ausgeführt werden. Mit Ausnahme von System.Debugsind diese Variablen schreibgeschützt, und ihre Werte werden automatisch vom System festgelegt. Einige der wichtigsten Variablen werden in den folgenden Tabellen beschrieben. Die vollständige 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 Azure Pipelines REST-APIs aufzurufen.

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

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

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

Beispiel: 1
System.TeamProject Der Name des Projekts, zu dem dieser Build oder dieses Release gehört.

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

Beispiel: 79f5c12e-3337-4151-be41-a268d2c73344
System.ArtifactsDirectory Das Verzeichnis, in das Artefakte während der Bereitstellung eines Release 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.

Beispiel: C:\agent\_work\r1\a
System.DefaultWorkingDirectory Das Verzeichnis, in das Artefakte während der Bereitstellung eines Release 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.

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

Beispiel: C:\agent\_work
System.Debug Dies ist die einzige Systemvariable, die von den Benutzern festgelegt werden kann. Legen Sie diese Einstellung auf TRUE fest, um das Release im Debugmodus auszuführen, um die Fehlersuche zu unterstützen.

Beispiel: true

Freigabe

Variablenname BESCHREIBUNG
Release.AttemptNumber Gibt an, wie oft dieses Release in dieser Phase bereitgestellt wird. In TFS 2015 nicht verfügbar.

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

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

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

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

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

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

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

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

Beispiel: 127
Release.EnvironmentId Die ID der Phaseninstanz in einem Release, für das die Bereitstellung gerade ausgeführt wird.

Beispiel: 276
Release.EnvironmentName Der Name der Phase, in der die Bereitstellung gerade ausgeführt wird.

Beispiel: Dev
Release.EnvironmentUri Der URI der Phaseninstanz in einem Release, für das die Bereitstellung gerade ausgeführt wird.

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

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

Beispiel: fabrikam\_web
Release.Reason Der Grund für die Bereitstellung. Diese Werte werden unterstützt:
ContinuousIntegration : Das Release wurde in Continuous Deployment gestartet, nachdem ein Build abgeschlossen wurde.
Manual : Das Release wurde manuell gestartet.
None : Der Bereitstellungsgrund wurde nicht angegeben.
Scheduled : Das Release wurde nach einem Zeitplan gestartet.
Release.ReleaseDescription Die Textbeschreibung, die zum Zeitpunkt der Veröffentlichung angegeben wurde.

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

Beispiel: 118
Release.ReleaseName Der Name des aktuellen Release.

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

Beispiel: vstfs://ReleaseManagement/Release/118
Release.ReleaseWebURL Die URL für dieses Release.

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

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

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

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

Beispiel: FALSE
Release.TriggeringArtifact.Alias Der Alias des Artefakts, das das Release ausgelöst hat. Dies ist leer, wenn das Release manuell geplant oder ausgelöst wurde.

Beispiel: fabrikam\_app

Releasephase

Variablenname BESCHREIBUNG
Release.Environments. {Phasenname}. Status Der Bereitstellungsstatus dieses Release innerhalb einer angegebenen Phase. In TFS 2015 nicht verfügbar.

Beispiel: NotStarted

Agent

Variablenname BESCHREIBUNG
Agent.Name Der Name des Agents, der beim Agentpoolregistriert ist. Dies unterscheidet sich wahrscheinlich vom Computernamen.

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

Beispiel: fabrikam-agent
Agent.Version Die Version der Agent-Software.

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

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.

Beispiel: C:\agent
Agent.ReleaseDirectory Das Verzeichnis, in das Artefakte während der Bereitstellung eines Release 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.

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

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.

Beispiel: C:\agent\_work
Agent.DeploymentGroupId Die ID der Bereitstellungsgruppe, bei der der Agent registriert ist. Dies ist nur in Bereitstellungsgruppe-Aufträgen verfügbar. Nicht verfügbar in TFS 2018 Update 1.

Beispiel: 1

Allgemeines Artefakt

Für jedes Artefakt, auf das in einem Release verwiesen wird, können Sie die folgenden Artefaktvariablen verwenden. Nicht alle Variablen sind für jeden Artefakttyp sinnvoll. Die folgende Tabelle listet die Standardartefaktvariablen auf und enthält Beispiele für die Werte, die sie je nach Artefakttyp haben. Wenn ein Beispiel leer ist, impliziert dies, dass die Variable für diesen Artefakttyp nicht aufgefüllt wird.

Ersetzen Sie den Platzhalter durch den Wert, den Sie für den {alias}{alias} angegeben haben, oder durch den Standardwert, der für die Releasepipeline generiert wurde.

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

Azure Pipelines Beispiel:1
GitHub Beispiel:fabrikam/asp
Release. Artifacts. {alias}. DefinitionName Der Name der Buildpipeline oder des Repositorys.

Azure Pipelines Beispiel:fabrikam-ci
TFVC-Beispiel: $/fabrikam
Git-Beispiel: fabrikam
GitHub Beispiel:fabrikam/asp (main)
Release. Artifacts. {alias}. Buildnumber Die Buildnummer oder der Commitbezeichner.

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

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

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

Azure Pipelines Beispiel:refs/heads/main
Release. Artifacts. {alias}. SourceBranchName Der name nur des Branchs, aus dem die Quelle erstellt wurde.

Azure Pipelines Beispiel:main
Release. Artifacts. {alias}. Sourceversion Der Commit, der erstellt wurde.

Azure Pipelines Beispiel:bc0044458ba1d9298cdc649cb5dcf013180706f7
Release. Artifacts. {alias}. Repository.Provider Der Typ des Repositorys, aus dem die Quelle erstellt wurde.

Azure Pipelines Beispiel:Git
Release. Artifacts. {alias}. RequestedForID Der Bezeichner des Kontos, das den Build ausgelöst hat.

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

Azure Pipelines Beispiel:Mateo Escobedo
Release. Artifacts. {alias}. Typ Der Typ der Artefaktquelle, z. B. Build.

Azure Pipelines Beispiel:Build
Jenkins-Beispiel: Jenkins
TeamCity-Beispiel: TeamCity
TFVC-Beispiel: TFVC
Git-Beispiel: Git
GitHub Beispiel:GitHub
Release. Artifacts. {alias}. PullRequest.TargetBranch Der vollständige Pfad und Name des Branchs, der das Ziel eines Pull Requests ist. Diese Variable wird nur initialisiert, wenn das Release durch einen Pull Request-Flow ausgelöst wird.

Azure Pipelines Beispiel:refs/heads/main
Release. Artifacts. {alias}. PullRequest.TargetBranchName Der name nur des Branchs, der das Ziel eines Pull Requests ist. Diese Variable wird nur initialisiert, wenn das Release durch einen Pull Request-Flow ausgelöst wird.

Azure Pipelines Beispiel:main

Siehe auch Artefaktquellenalias.

Primäres Artefakt

Sie bestimmen eines der Artefakte als primäres Artefakt in einer Releasepipeline. Für das designierte primäre Artefakt Azure Pipelines die folgenden Variablen auf.

Variablenname Identisch mit
Build.DefinitionId Release. Artifacts. {Primärer Artefaktalias}. DefinitionId
Build.DefinitionName Release. Artifacts. {Primärer Artefaktalias}. DefinitionName
Build.BuildNumber Release. Artifacts. {Primärer Artefaktalias}. Buildnumber
Build.BuildId Release. Artifacts. {Primärer Artefaktalias}. BuildId
Build.BuildURI Release. Artifacts. {Primärer Artefaktalias}. BuildURI
Build.SourceBranch Release. Artifacts. {Primärer Artefaktalias}. SourceBranch
Build.SourceBranchName Release. Artifacts. {Primärer Artefaktalias}. SourceBranchName
Build.SourceVersion Release. Artifacts. {Primärer Artefaktalias}. Sourceversion
Build.Repository.Provider Release. Artifacts. {Primärer Artefaktalias}. Repository.Provider
Build.RequestedForID Release. Artifacts. {Primärer Artefaktalias}. RequestedForID
Build.RequestedFor Release. Artifacts. {Primärer Artefaktalias}. RequestedFor
Build.Type Release. Artifacts. {Primärer Artefaktalias}. Typ
Build.PullRequest.TargetBranch Release. Artifacts. {Primärer Artefaktalias}. PullRequest.TargetBranch
Build.PullRequest.TargetBranchName Release. Artifacts. {Primärer Artefaktalias}. PullRequest.TargetBranchName

Verwenden von Standardvariablen

Sie können die Standardvariablen auf zwei Arten verwenden: als Parameter für Aufgaben in einer Releasepipeline oder in Ihren Skripts.

Sie können eine Standardvariable direkt als Eingabe für eine Aufgabe verwenden. Zum Beispiel , um Release.Artifacts.{Artifact alias}.DefinitionName für die Artefaktquelle zu übergeben, deren Alias Release.Artifacts.{Artifact alias}.DefinitionName für eine Aufgabe, verwenden Sie $(Release.Artifacts.ASPNET4.CI.DefinitionName) .

Verwenden von Artefaktvariablen in Argumenten für einen PowerShell-Skripttask

Um eine Standardvariable in Ihrem Skript zu verwenden, müssen Sie zuerst . in den Standardvariablennamen durch _ ersetzen. Um z. B. den Wert der Artefaktvariable Release.Artifacts.{Artifact alias}.DefinitionName für die Artefaktquelle ausgibt, deren Alias Release.Artifacts.{Artifact alias}.DefinitionName in einem PowerShell-Skript verwenden Sie $env:RELEASE_ARTIFACTS_ASPNET4_CI_DEFINITIONNAME .

Verwenden von Artefaktvariablen in einem Inline-PowerShell-Skript

Beachten Sie, dass der ursprüngliche Name des Artefaktquellenalias durch ASPNET4.CI ersetzt ASPNET4_CI wird.

Anzeigen der aktuellen Werte aller Variablen

  1. Öffnen Sie die Pipelineansicht der Zusammenfassung für das Release, und wählen Sie die Phase aus, an der Sie interessiert sind. Wählen Sie in der Liste der Schritte die Option Auftrag initialisierenaus.

    Öffnen des Protokolls für ein Release

  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 einem Release

Ausführen eines Releases im Debugmodus

Zeigen Sie zusätzliche Informationen an, während ein Release ausgeführt wird, und in den Protokolldateien, indem Sie das gesamte Release oder nur die Aufgaben in einer einzelnen Releasephase im Debugmodus ausführen. Dies kann Ihnen helfen, Probleme und Fehler zu beheben.

  • Um den Debugmodus für ein gesamtes Release zu initiieren, fügen Sie System.Debug der Registerkarte Variablen einer Releasepipeline eine Variable namens mit dem Wert true hinzu. System.Debug

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

  • Alternativ können Sie eine Variablengruppe erstellen, die eine Variable namens mit dem Wert enthält, und diese true Variablengruppe mit einer Releasepipeline verknüpfen.

Tipp

Wenn sie einen Fehler im Zusammenhang mit einer Azure RM-Dienstverbindung erhalten, finden Sie weitere Informationen unter Vorgehensweise: Problembehandlung bei Azure Resource Manager Dienstverbindungen.

Benutzerdefinierte Variablen

Benutzerdefinierte Variablen können in verschiedenen Bereichen definiert werden.

  • Geben Sie Werte für alle Definitionen in einem Projekt frei, indem Sie Variablengruppen verwenden. Wählen Sie eine Variablengruppe aus, wenn Sie die gleichen Werte für alle Definitionen, Phasen und Aufgaben in einem Projekt verwenden müssen und die Werte an einem zentralen Ort ändern können möchten. Sie definieren und verwalten Variablengruppen auf der Registerkarte Bibliothek.

  • Geben Sie Werte für alle Phasen frei, indem Sie Releasepipelinevariablenverwenden. Wählen Sie eine Releasepipelinevariable aus, wenn Sie denselben Wert für alle Phasen und Aufgaben in der Releasepipeline verwenden müssen und den Wert an einem zentralen Ort ändern möchten. 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 sie standardmäßig auf Releasebereich festgelegt.

  • Verwenden Sie die Phasenvariablen, um Werte für alle Aufgaben innerhalb einer bestimmten Phase freizugeben. Verwenden Sie eine Variable auf Stufenebene für Werte, die von Phase zu Stufe variieren (und für alle Aufgaben in einer Phase gleich sind). 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-, Releasepipeline- und Phasenbereich unterstützt Sie bei folgenden Aufgaben:

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

  • Store sensible Werte so, dass sie von Benutzern der Releasepipelines nicht angezeigt oder geändert werden können. Legen Sie eine Konfigurationseigenschaft als sichere (geheime) Variable fest, indem Sie das Vorhängeschlosssymbol neben der Variablen auswählen.

    Wichtig

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

Hinweis

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

Verwenden von benutzerdefinierten Variablen

Um benutzerdefinierte Variablen in Ihren Build- und Releasetasks zu verwenden, schließen Sie einfach den Variablennamen in Klammern ein, und setzen Sie ihm ein $ Zeichen voran. Wenn Sie beispielsweise über eine Variable mit dem Namen adminUserNameverfügen, können Sie den aktuellen Wert dieser Variablen in einen Parameter einer Aufgabe als einfügen.

Hinweis

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

Definieren und Ändern ihrer Variablen in einem Skript

Verwenden Sie den Protokollierungsbefehl, um eine Variable aus einem Skript zu definieren oder zu task.setvariable ändern. Beachten Sie, dass der aktualisierte Variablenwert auf den ausgeführten Auftrag verteilt 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. Auf Windows greifen Sie als oder darauf %AGENT_WORKFOLDER%$env:AGENT_WORKFOLDER zu. Unter Linux und macOS verwenden Sie $AGENT_WORKFOLDER .

Tipp

Sie können ein Skript für folgendes ausführen:

Batchskript

Festlegen der Variablen und 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 beim 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)