Klassische Freigabe- und Artefaktevariablen

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

Hinweis

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

Klassische Freigabe- und Artefaktevariablen sind eine bequeme Möglichkeit, Daten in Ihrer Pipeline zu austauschen und zu transportieren. Jede Variable wird als Zeichenfolge gespeichert und der Wert kann zwischen Ausführungen ihrer Pipeline geändert werden.

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 gefüllt.

Wenn Sie die Aufgaben zum Bereitstellen Ihrer Anwendung in jede Phase in Ihren DevOps CI/CD-Prozessen verfassen, helfen Variablen Ihnen folgendes:

  • 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 Stufe 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 es herunterzuladen oder das Arbeitsverzeichnis im Agent zum Erstellen temporärer 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 Vorgängen ü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 Azure Pipelines REST-APIs aufzurufen.

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 Versionskontrolle aufzurufen.

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

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.

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

Beispiel: Fabrikam
System.TeamProjectId Die ID des Projekts, zu dem dieser Build oder diese Version 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 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.

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.

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.

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.

Beispiel: true

Release

Variablenname BESCHREIBUNG
Release.AttemptNumber Die Anzahl der Zeiten, in denen diese Version 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 die aktuelle Version 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 Bereitstellung zurzeit 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 Bereitstellung zurzeit ausgelöst hat (gestartet). In TFS 2015 nicht verfügbar.

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.

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 einer Version, für die die Bereitstellung derzeit ausgeführt wird.

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

Beispiel: Dev
Release.EnvironmentUri Der URI der Phaseninstanz in einer Version, in der die Bereitstellung derzeit 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 Artefaktequelle

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.
Scheduled - die Veröffentlichung wurde aus einem Zeitplan gestartet.
Release.ReleaseDescription Die Textbeschreibung, die zur Zeit der Veröffentlichung bereitgestellt wird.

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

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

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

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

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.

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

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

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

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.

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.

Beispiel: NotStarted

Agent

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

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

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

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

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.

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, für die der Agent registriert ist. Dies ist nur in Bereitstellungsgruppenaufträgen verfügbar. In TFS 2018 Update 1 nicht verfügbar.

Beispiel: 1

Allgemeines Artefakt

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 Standardartefaktvariablen aufgeführt und beispiele für die Werte aufgeführt, die sie je nach Artefakttyp aufweisen. Wenn ein Beispiel leer ist, bedeutet dies, dass die Variable für diesen Artefakttyp nicht aufgefüllt wird.

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

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 der Verzweigung, aus der die Quelle erstellt wurde.

Azure Pipelines Beispiel:refs/heads/main
Release. Artifacts. {alias}. SourceBranchName Der Name nur der Verzweigung, aus der 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 Art der Art der Artefakte, 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 der Verzweigung, die das Ziel einer Pullanforderung ist. Diese Variable wird nur initialisiert, wenn die Veröffentlichung durch einen Pullanforderungsfluss ausgelöst wird.

Azure Pipelines Beispiel:refs/heads/main
Release. Artifacts. {alias}. PullRequest.TargetBranchName Der Name nur der Verzweigung, die das Ziel einer Pullanforderung ist. Diese Variable wird nur initialisiert, wenn die Veröffentlichung durch einen Pullanforderungsfluss ausgelöst wird.

Azure Pipelines Beispiel:main

Siehe auch Artefaktquellenalias

Primäres Artefakt

Sie legen eines 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. Artifacts. {Primärer Artefaktealias}. DefinitionId
Build.DefinitionName Release. Artifacts. {Primärer Artefaktealias}. DefinitionName
Build.BuildNumber Release. Artifacts. {Primärer Artefaktealias}. Buildnumber
Build.BuildId Release. Artifacts. {Primärer Artefaktealias}. BuildId
Build.BuildURI Release. Artifacts. {Primärer Artefaktealias}. BuildURI
Build.SourceBranch Release. Artifacts. {Primärer Artefaktealias}. SourceBranch
Build.SourceBranchName Release. Artifacts. {Primärer Artefaktealias}. SourceBranchName
Build.SourceVersion Release. Artifacts. {Primärer Artefaktealias}. Sourceversion
Build.Repository.Provider Release. Artifacts. {Primärer Artefaktealias}. Repository.Provider
Build.RequestedForID Release. Artifacts. {Primärer Artefaktealias}. RequestedForID
Build.RequestedFor Release. Artifacts. {Primärer Artefaktealias}. RequestedFor
Build.Type Release. Artifacts. {Primärer Artefaktealias}. Typ
Build.PullRequest.TargetBranch Release. Artifacts. {Primärer Artefaktealias}. PullRequest.TargetBranch
Build.PullRequest.TargetBranchName Release. Artifacts. {Primärer Artefaktealias}. 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 für die Artefaktquelle ü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).

Using artifact variables in arguments to a PowerShell Script task

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

Using artifact variables in an inline PowerShell script

Beachten Sie, dass der ursprüngliche Name des Artefaktquellenalias, ASPNET4.CIdurch ASPNET4_CIersetzt wird.

Anzeigen der aktuellen Werte aller Variablen

  1. Öffnen Sie die Pipelineansicht der Zusammenfassung für die Version, und wählen Sie die Phase aus, an der Sie interessiert sind. Wählen Sie in der Liste der Schritte den Befehl "Initialisieren" aus.

    Opening the log for a 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.

    Viewing the values of the variables in a release

Ausführen eines Releases im Debugmodus

Zeigen Sie zusätzliche Informationen als Version an, die ausgeführt und in den Protokolldateien ausgeführt werden, indem Sie die gesamte Version ausführen oder nur die Aufgaben in einer einzelnen Versionsphase im Debugmodus ausführen. Dies kann Ihnen helfen, Probleme und Fehler zu beheben.

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

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

  • Erstellen Sie alternativ eine Variablengruppe , die eine Variable System.Debug mit dem Wert true enthält, und verknüpfen Sie diese Variablengruppe 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 für alle Definitionen in einem Projekt mithilfe von Variablengruppen. Wählen Sie eine Variablengruppe aus, wenn Sie dieselben 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 "Freigeben" aus. Wenn Sie eine Variable hinzufügen, wird sie standardmäßig auf den Bereich "Release" festgelegt.

  • Freigeben von Werten innerhalb aller Aufgaben innerhalb einer bestimmten Phase mithilfe von Phasenvariablen. Verwenden Sie eine Variable auf Stufe für Werte, die von Stufe zu Stufe variieren (und sind für alle Vorgänge 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-, Releasepipeline- und Phasenbereich hilft Ihnen dabei:

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

  • Store 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 das padlock Symbol (Vorhängeschloss) neben der Variablen 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, wenn auf die Aufgaben verwiesen wird, und übergibt sie über einen sicheren HTTPS-Kanal an den Agent.

Hinweis

Das Erstellen benutzerdefinierter Variablen kann Standardvariablen überschreiben. Beispielsweise die PowerShell Path-Umgebungsvariable. Wenn Sie eine benutzerdefinierte Path Variable für einen Windows Agent erstellen, überschreibt sie die $env:Path Variable, und PowerShell kann nicht ausgeführt werden.

Verwenden von benutzerdefinierten Variablen

Wenn Sie benutzerdefinierte Variablen in Ihren Build- und Freigabeaufgaben verwenden möchten, schließen Sie einfach den Variablennamen in Klammern ein, und stellen Sie ihm ein $ Zeichen voran. Wenn Sie beispielsweise über eine Variable namens "adminUserName" verfügen, können Sie den aktuellen Wert dieser Variable in einen Parameter einer Aufgabe einfügen als $(adminUserName).

Hinweis

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

Definieren und Ändern ihrer Variablen in einem Skript

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

Agent.WorkFolder wird beispielsweise zu AGENT_WORKFOLDER. Auf Windows greifen Sie auf dies als %AGENT_WORKFOLDER% oder $env:AGENT_WORKFOLDER. Unter 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)