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: 1GitHub Beispiel: fabrikam/asp |
| Release. Artifacts. {alias}. DefinitionName | Der Name der Buildpipeline oder des Repositorys. Azure Pipelines Beispiel: fabrikam-ciTFVC-Beispiel: $/fabrikamGit-Beispiel: fabrikamGitHub Beispiel: fabrikam/asp (main) |
| Release. Artifacts. {alias}. Buildnumber | Die Buildnummer oder der Commitbezeichner. Azure Pipelines Beispiel: 20170112.1Jenkins/TeamCity-Beispiel: 20170112.1TFVC-Beispiel: Changeset 3Git-Beispiel: 38629c964GitHub Beispiel: 38629c964 |
| Release. Artifacts. {alias}. BuildId | Der Buildbezeichner. Azure Pipelines Beispiel: 130Jenkins/TeamCity-Beispiel: 130GitHub Beispiel: 38629c964d21fe405ef830b7d0220966b82c9e11 |
| Release. Artifacts. {alias}. BuildURI | Die URL für den Build. Azure Pipelines Beispiel: vstfs://build-release/Build/130GitHub 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: BuildJenkins Beispiel: JenkinsTeamCity-Beispiel: TeamCityTFVC-Beispiel: TFVCGit-Beispiel: GitGitHub 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).
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.
Beachten Sie, dass der ursprüngliche Name des Artefaktquellenalias, ASPNET4.CIdurch ASPNET4_CIersetzt wird.
Anzeigen der aktuellen Werte aller Variablen
Ö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.
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 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.Debugmit dem Namen "Variablentrue" 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.Debugmit dem Namen "Werttrue" zur Registerkarte "Variablen " hinzu.Erstellen Sie alternativ eine Variablengruppe , die eine Variable
System.Debugmit dem Werttrueenthä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
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:
- 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)