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: 1GitHub-Beispiel: fabrikam/asp |
| Release.Artefakte. {alias}. DefinitionName | Der Name der Buildpipeline oder des Repositorys. Beispiel für Azure-Pipelines: fabrikam-ciTFVC-Beispiel: $/fabrikamGit-Beispiel: fabrikamGitHub-Beispiel: fabrikam/asp (main) |
| Release.Artefakte. {alias}. Buildnumber | Die Buildnummer oder der Commit-Bezeichner. Beispiel für Azure-Pipelines: 20170112.1Jenkins/TeamCity-Beispiel: 20170112.1TFVC-Beispiel: Changeset 3Git-Beispiel: 38629c964GitHub-Beispiel: 38629c964 |
| Release.Artefakte. {alias}. BuildId | Der Buildbezeichner. Beispiel für Azure-Pipelines: 130Jenkins/TeamCity-Beispiel: 130GitHub-Beispiel: 38629c964d21fe405ef830b7d0220966b82c9e11 |
| Release.Artefakte. {alias}. BuildURI | Die URL für den Build. Beispiel für Azure-Pipelines: vstfs://build-release/Build/130GitHub-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: BuildJenkins Beispiel: JenkinsTeamCity-Beispiel: TeamCityTFVC-Beispiel: TFVCGit-Beispiel: GitGitHub-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).
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.
Beachten Sie, dass der ursprüngliche Name des Artefaktequelle-Aliass ASPNET4.CIersetzt ASPNET4_CIwird.
Anzeigen der aktuellen Werte aller Variablen
Ö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.
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.
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
trueenthält, und verknüpfen Sie diese VariablengruppeSystem.Debugmit 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 "
) 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:
- Windows-Agent mit einer Batchskriptaufgabe oder PowerShell-Skriptaufgabe.
- macOS - oder Linux-Agent mit einer Shell-Skriptaufgabe.
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)
Festlegen der 
Festlegen der 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)