Klassische Release- und Artefaktvariablen
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
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ührungen Ihrer Pipeline ändern.
Variablen unterscheiden sich von Laufzeitparametern, die nur beim Parsen der Vorlage verfügbar sind.
Wenn Sie die Aufgaben für die Bereitstellung Ihrer Anwendung in jeder Stage Ihrer DevOps CI/CD-Prozesse zusammenstellen, bieten Variablen Unterstützung bei folgenden Aufgaben:
Einmaliges Definieren einer generischen Bereitstellungspipeline, die dann für jede Stage problemlos angepasst werden kann. Beispielsweise kann die Verbindungszeichenfolge für die Webbereitstellung durch eine Variable dargestellt werden, deren Wert von einer Stage zur nächsten geändert werden kann. Dies sind benutzerdefinierte Variablen.
Verwenden von Informationen zum Kontext der jeweiligen Releases, Stages, Artefakte oder Agents, in denen die Bereitstellungspipeline ausgeführt wird. Ihr Skript benötigt zum Beispiel Zugriff auf den Speicherort des Builds, um ihn herunterzuladen, oder auf das Arbeitsverzeichnis des Agents, um temporäre Dateien zu erstellen. Dies sind Standardvariablen.
Hinweis
Weitere Informationen zu YAML-Pipelines finden Sie unter Benutzerdefinierte Variablen und Vordefinierte Variablen.
Standardvariablen
Informationen zum Ausführungskontext werden den aktuell ausgeführten Aufgaben über Standardvariablen zur Verfügung gestellt. Ihre Aufgaben und Skripts können diese Variablen verwenden, um Informationen zum System, zum Release, zur Stage oder zum Agent zu finden, in dem bzw. der 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. Eine vollständige Liste finden Sie unter Anzeigen der aktuellen Werte aller Variablen.
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.
System
| Variablenname | BESCHREIBUNG |
|---|---|
| System.TeamFoundationServerUri | Die URL der Dienstverbindung in Azure Pipelines. Verwenden Sie diese in 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 von Azure Pipelines. Verwenden Sie diese in Ihren Skripts oder Aufgaben, um REST-APIs für andere Dienste (z. B. den Builddienst und die Versionskontrolle) aufzurufen. Beispiel: https://dev.azure.com/fabrikam/ |
| System.CollectionId | Die ID der Sammlung, der dieser Build oder dieses Release angehört. Beispiel: 6c6f3423-1c84-4625-995a-f7f143a1e43d |
| System.DefinitionId | Die ID der Releasepipeline, der das aktuelle Release angehört. Beispiel: 1 |
| System.TeamProject | Der Name des Projekts, dem dieser Build oder dieses Release angehört. Beispiel: Fabrikam |
| System.TeamProjectId | Die ID des Projekts, dem dieser Build oder dieses Release angehört. Beispiel: 79f5c12e-3337-4151-be41-a268d2c73344 |
| System.ArtifactsDirectory | Das Verzeichnis, in das die Artefakte bei der Bereitstellung eines Releases 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 die Artefakte bei der Bereitstellung eines Releases 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 für jeden Build oder jedes Release Unterordner erstellt werden. Identisch mit „Agent.RootDirectory“ und „Agent.WorkFolder“. Beispiel: C:\agent\_work |
| System.Debug | Dies ist die einzige Systemvariable, die von den Benutzer*innen festgelegt werden kann. Bei einer Festlegung auf TRUE wird das Release im Debugmodus ausgeführt, um die Fehlersuche zu unterstützen. Beispiel: true |
Freigabe
| Variablenname | BESCHREIBUNG |
|---|---|
| Release.AttemptNumber | Gibt an, wie oft dieses Release in dieser Stage bereitgestellt wird. Beispiel: 1 |
| Release.DefinitionEnvironmentId | Die ID der Stage in der entsprechenden Releasepipeline. Beispiel: 1 |
| Release.DefinitionId | Die ID der Releasepipeline, der das aktuelle Release angehört. 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 derzeit durchgeführte Bereitstellung ausgelöst (gestartet) hat. Beispiel: Mateo Escobedo |
| Release.Deployment.RequestedForEmail | Die E-Mail-Adresse der Identität, die die derzeit durchgeführte Bereitstellung ausgelöst (gestartet) hat. Beispiel: mateo@fabrikam.com |
| Release.Deployment.RequestedForId | Die ID der Identität, die die derzeit durchgeführte Bereitstellung ausgelöst (gestartet) hat. 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 durchgeführt wird. Beispiel: 127 |
| Release.EnvironmentId | Die ID der Stage-Instanz in einem Release, für das die Bereitstellung derzeit durchgeführt wird. Beispiel: 276 |
| Release.EnvironmentName | Der Name der Stage, für die derzeit die Bereitstellung durchgeführt wird. Beispiel: Dev |
| Release.EnvironmentUri | Der URI der Stage-Instanz in einem Release, für das die Bereitstellung derzeit durchgeführt wird. Beispiel: vstfs://ReleaseManagement/Environment/276 |
| Release.Environments.{stage-name}.status | Der Bereitstellungsstatus der Stage. 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 im Continuous Deployment-Modus gestartet, nachdem ein Build abgeschlossen wurde.Manual: Das Release wurde manuell gestartet.None: Der Bereitstellungsgrund wurde nicht angegeben.Schedule: Das Release wurde über einen Zeitplan gestartet. |
| Release.ReleaseDescription | Die Textbeschreibung, die zum Zeitpunkt der Veröffentlichung bereitgestellt wurde. Beispiel: Critical security patch |
| Release.ReleaseId | Der Bezeichner des aktuellen Releasedatensatzes. Beispiel: 118 |
| Release.ReleaseName | Der Name des aktuellen Releases. Beispiel: Release-47 |
| Release.ReleaseUri | Der URI des aktuellen Releases. 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. Dieser Wert ist leer, wenn das Release geplant oder manuell ausgelöst wurde. Beispiel: fabrikam\_app |
Releasestage
| Variablenname | BESCHREIBUNG |
|---|---|
| Release.Environments.{stage name}.Status | Der Bereitstellungsstatus dieses Releases innerhalb einer angegebenen Stage. Beispiel: NotStarted |
Agent
| Variablenname | BESCHREIBUNG |
|---|---|
| Agent.Name | Der Name des Agents, wie er im Agentpool registriert ist. Dieser 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 Agentsoftware. Beispiel: 2.109.1 |
| Agent.JobName | Der Name des ausgeführten Auftrags, 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 die Artefakte bei der Bereitstellung eines Releases 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 für jeden Build oder jedes Release Unterordner erstellt werden. Identisch mit „Agent.WorkFolder“ und „System.WorkFolder“. Beispiel: C:\agent\_work |
| Agent.WorkFolder | Das Arbeitsverzeichnis für diesen Agent, in dem für jeden Build oder jedes Release Unterordner 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. Nur in Bereitstellungsgruppenaufträgen verfügbar. 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 aussagekräftig. In der folgenden Tabelle finden Sie eine Liste der standardmäßigen Artefaktvariablen und Beispiele für die Werte, 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 Platzhalter {alias} durch den für den Artefaktalias angegebenen Wert oder durch den für die Releasepipeline generierten Standardwert.
| Variablenname | BESCHREIBUNG |
|---|---|
| Release.Artifacts.{alias}.DefinitionId | Der Bezeichner der Buildpipeline oder des Repositorys. Beispiel für Azure Pipelines: 1GitHub-Beispiel: fabrikam/asp |
| Release.Artifacts.{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.Artifacts.{alias}.BuildNumber | Die Buildnummer oder der Commitbezeichner. Beispiel für Azure Pipelines: 20170112.1Jenkins/TeamCity-Beispiel: 20170112.1TFVC-Beispiel: Changeset 3Git-Beispiel: 38629c964GitHub-Beispiel: 38629c964 |
| Release.Artifacts.{alias}.BuildId | Der Buildbezeichner. Beispiel für Azure Pipelines: 130Jenkins/TeamCity-Beispiel: 130GitHub-Beispiel: 38629c964d21fe405ef830b7d0220966b82c9e11 |
| Release.Artifacts.{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.Artifacts.{alias}.SourceBranch | Der vollständige Pfad und Name des Branchs, aus dem die Quelle erstellt wurde. Beispiel für Azure Pipelines: refs/heads/main |
| Release.Artifacts.{alias}.SourceBranchName | Nur der Name des Branchs, aus dem die Quelle erstellt wurde. Beispiel für Azure Pipelines: main |
| Release.Artifacts.{alias}.SourceVersion | Der erstellte Commit. Beispiel für Azure Pipelines: bc0044458ba1d9298cdc649cb5dcf013180706f7 |
| Release.Artifacts.{alias}.Repository.Provider | Der Typ des Repositorys, aus dem die Quelle erstellt wurde. Beispiel für Azure Pipelines: Git |
| Release.Artifacts.{alias}.RequestedForID | Der Bezeichner des Kontos, das den Build ausgelöst hat. Beispiel für Azure Pipelines: 2f435d07-769f-4e46-849d-10d1ab9ba6ab |
| Release.Artifacts.{alias}.RequestedFor | Der Name des Kontos, das den Build angefordert hat. Beispiel für Azure Pipelines: Mateo Escobedo |
| Release.Artifacts.{alias}.Type | Der Typ der Artefaktquelle, z. B. „Build“. Beispiel für Azure Pipelines: BuildJenkins-Beispiel: JenkinsTeamCity-Beispiel: TeamCityTFVC-Beispiel: TFVCGit-Beispiel: GitGitHub-Beispiel: GitHub |
| Release.Artifacts.{alias}.PullRequest.TargetBranch | Der vollständige Pfad und Name des Branchs, der das Ziel von einem Pull Request ist. Diese Variable wird nur initialisiert, wenn das Release durch einen Pull Request-Flow ausgelöst wird. Beispiel für Azure Pipelines: refs/heads/main |
| Release.Artifacts.{alias}.PullRequest.TargetBranchName | Nur der Name des Branchs, der das Ziel von einem Pull Request ist. Diese Variable wird nur initialisiert, wenn das Release durch einen Pull Request-Flow ausgelöst wird. Beispiel für Azure Pipelines: main |
Siehe auch Artefaktquellenalias.
Primäres Artefakt
Sie legen eines der Artefakte als primäres Artefakt in einer Releasepipeline fest. Für das angegebene primäre Artefakt füllt Azure Pipelines die folgenden Variablen auf.
| Variablenname | Identisch mit |
|---|---|
| Build.DefinitionId | Release.Artifacts.{Primary artifact alias}.DefinitionId |
| Build.DefinitionName | Release.Artifacts.{Primary artifact alias}.DefinitionName |
| Build.BuildNumber | Release.Artifacts.{Primary artifact alias}.BuildNumber |
| Build.BuildId | Release.Artifacts.{Primary artifact alias}.BuildId |
| Build.BuildURI | Release.Artifacts.{Primary artifact alias}.BuildURI |
| Build.SourceBranch | Release.Artifacts.{Primary artifact alias}.SourceBranch |
| Build.SourceBranchName | Release.Artifacts.{Primary artifact alias}.SourceBranchName |
| Build.SourceVersion | Release.Artifacts.{Primary artifact alias}.SourceVersion |
| Build.Repository.Provider | Release.Artifacts.{Primary artifact alias}.Repository.Provider |
| Build.RequestedForID | Release.Artifacts.{Primary artifact alias}.RequestedForID |
| Build.RequestedFor | Release.Artifacts.{Primary artifact alias}.RequestedFor |
| Build.Type | Release.Artifacts.{Primary artifact alias}.Type |
| Build.PullRequest.TargetBranch | Release.Artifacts.{Primary artifact alias}.PullRequest.TargetBranch |
| Build.PullRequest.TargetBranchName | Release.Artifacts.{Primary artifact alias}.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.
Um zum Beispiel Release.Artifacts.{Artifact alias}.DefinitionName für die Artefaktquelle mit dem Alias ASPNET4.CI an eine Aufgabe zu übergeben, würden Sie $(Release.Artifacts.ASPNET4.CI.DefinitionName) verwenden.
Um eine Standardvariable in Ihrem Skript zu verwenden, müssen Sie zunächst den . im Namen der Standardvariable durch _ ersetzen.
Wenn Sie beispielsweise den Wert der Artefaktvariablen Release.Artifacts.{Artifact alias}.DefinitionName für die Artefaktquelle mit dem Alias ASPNET4.CI in einem PowerShell-Skript ausgeben möchten, würden Sie $env:RELEASE_ARTIFACTS_ASPNET4_CI_DEFINITIONNAME verwenden.
Beachten Sie, dass der ursprüngliche Name des Artefaktquellenalias (ASPNET4.CI) durch ASPNET4_CI ersetzt wird.
Anzeigen der aktuellen Werte aller Variablen
Öffnen Sie die Pipelineansicht der Zusammenfassung für das Release, und wählen Sie die gewünschte Stage aus. Wählen Sie in der Liste der Schritte Auftrag initialisieren aus.
Dadurch wird das Protokoll für diesen Schritt geöffnet. Scrollen Sie nach unten, um die vom Agent für diesen Auftrag verwendeten Werte anzuzeigen.
Ausführen eines Releases im Debugmodus
Zeigen Sie während der Ausführung eines Releases und in den Protokolldateien zusätzliche Informationen an, indem Sie das gesamte Release oder nur die Aufgaben in einer einzelnen Releasestage im Debugmodus ausführen. Dies kann Ihnen helfen, Probleme und Fehler zu beheben.
Um den Debugmodus für ein gesamtes Release zu aktivieren, fügen Sie auf der Registerkarte
System.DebugVariablentrueeiner Releasepipeline eine Variable namens mit dem Wert hinzu.Um den Debugmodus für eine einzelne Stage zu starten, öffnen Sie das Dialogfeld Stage konfigurieren aus dem Kontextmenü der Stage und fügen auf der Registerkarte
System.DebugVariablentrueeine Variable mit dem Namen und dem Wert hinzu.Alternativ können Sie eine Variablengruppe erstellen, die eine Variable namens
System.Debugmit dem Werttrueenthält, und diese Variablengruppe mit einer Releasepipeline verknüpfen.
Tipp
Wenn Sie eine Fehlermeldung im Zusammenhang mit einer Azure RM-Dienstverbindung erhalten, erhalten Sie unter Problembehandlung für ARM-Dienstverbindungen weitere Informationen.
Benutzerdefinierte Variablen
Benutzerdefinierte Variablen können in verschiedenen Bereichen definiert werden.
Verwenden Sie Variablengruppen, um Werte für alle Definitionen in einem Projekt gemeinsam zu nutzen. Wählen Sie eine Variablengruppe, wenn Sie dieselben Werte für alle Definitionen, Stages und Aufgaben in einem Projekt verwenden müssen und in der Lage sein möchten, die Werte zentral zu ändern. Sie definieren und verwalten Variablengruppen auf der Registerkarte Bibliothek.
Geben Sie Werte für alle Stages frei, indem Sie Releasepipelinevariablen verwenden. Wählen Sie eine Releasepipelinevariable, wenn Sie denselben Wert für alle Stages und Aufgaben in der Releasepipeline verwenden müssen und in der Lage sein möchten, die Werte zentral zu ändern. 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 den Bereich „Release“ festgelegt.
Verwenden Sie Stagevariablen, um Werte für alle Aufgaben innerhalb einer bestimmten Stage freizugeben. Verwenden Sie eine Variable auf Stageebene für Werte, die von Stage zu Stage variieren (und für alle Aufgaben in einer Stage gleich sind). 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 die erforderliche Stage aus. Wenn Sie eine Variable hinzufügen, legen Sie den Bereich auf die geeignete Umgebung fest.
Die Verwendung benutzerdefinierter Variablen im Projekt-, Releasepipeline- und Stagebereich ermöglicht Folgendes:
Vermeidung von doppelten Werten, wodurch es einfacher wird, alle Vorkommen in einem Vorgang zu aktualisieren.
Sensible Werte werden so gespeichert, dass sie von Benutzer*innen der Releasepipelines weder eingesehen noch geändert werden können. Kennzeichnen Sie eine Konfigurationseigenschaft als sichere (geheime) Variable, indem Sie das Symbol
(Vorhängeschloss) neben der Variablen auswählen.Wichtig
Die Werte der ausgeblendeten (geheimen) Variablen werden sicher auf dem Server gespeichert und können von Benutzer*innen nach dem Speichern nicht mehr angezeigt werden. Während einer Bereitstellung entschlüsselt der Azure Pipelines-Releasedienst diese Werte (sofern sie von den Aufgaben referenziert werden) und leitet sie über einen sicheren HTTPS-Kanal an den Agent weiter.
Hinweis
Durch das Erstellen von benutzerdefinierten Variablen können Standardvariablen überschrieben werden. Beispiel: Die PowerShell-Umgebungsvariable Path. Wenn Sie eine benutzerdefinierte Path-Variable für einen Windows-Agent erstellen, überschreibt diese die $env:Path-Variable, und die PowerShell kann nicht ausgeführt werden.
Verwenden von benutzerdefinierten Variablen
Um benutzerdefinierte Variablen in Ihren Build- und Releaseaufgaben zu verwenden, schließen Sie den Variablennamen einfach in Klammern ein und stellen ihm ein $-Zeichen voran. Wenn Sie z. B. über eine Variable mit dem Namen adminUserName verfügen, können Sie den aktuellen Wert dieser Variable als $(adminUserName) in einen Parameter einer Aufgabe einfügen.
Hinweis
Variablen in verschiedenen Gruppen, die mit einer Pipeline im selben Bereich (z. B. Auftrag oder Stage) verknüpft sind, führen zu Konflikten und können zu unvorhersehbaren Ergebnissen führen. Stellen Sie sicher, dass Sie für Variablen in allen Variablengruppen unterschiedliche Namen verwenden.
Definieren und Ändern Ihrer Variablen in einem Skript
Wenn Sie eine Variable über ein Skript definieren oder ändern möchten, verwenden Sie den Protokollierungsbefehl task.setvariable.
Beachten Sie, dass der aktualisierte Variablenwert auf den derzeit ausgeführten Auftrag beschränkt ist und nicht über Aufträge oder Stages hinweg weitergegeben wird.
Variablennamen werden in Großbuchstaben umgewandelt, und die Zeichen „.“ und „ “ werden durch „_“ ersetzt.
Agent.WorkFolder wird beispielsweise zu AGENT_WORKFOLDER.
Unter Windows erfolgt der Zugriff als %AGENT_WORKFOLDER% oder $env:AGENT_WORKFOLDER.
Unter Linux und macOS verwenden Sie $AGENT_WORKFOLDER.
Tipp
Ein Skript kann über folgende Agents ausgeführt werden:
- Windows-Agent (entweder mit einem Batch-Skripttask oder mit einem PowerShell-Skripttask)
- macOS- oder Linux-Agent (mit einem Shell-Skripttask)
Batchskript
Festlegen der Variablen sauce 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)
Festlegen der Variablen 
Festlegen der Variablen Konsolenausgabe nach 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)
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für