Kontext des Pipelinedekororausdrucks

Artikel
11/09/2024

Azure DevOps Services

Pipelinedekortoren haben Zugriff auf kontextbezogene Informationen zur Pipeline, in der sie ausgeführt werden. Als Autor des Pipelinedekorors können Sie diesen Kontext verwenden, um Entscheidungen über das Verhalten des Dekorators zu treffen. Die im Kontext verfügbaren Informationen unterscheiden sich für Pipelines und für die Freigabe. Außerdem werden Dekorateure ausgeführt, nachdem Aufgabennamen in GUIDs (Globally Unique Identifier) aufgelöst wurden. Wenn Ihr Dekorateur auf eine Aufgabe verweisen möchte, sollte sie anstelle des Namens oder Schlüsselworts die GUID verwenden.

Tipp

Sehen Sie sich unsere neueste Dokumentation zur Erweiterungsentwicklung mithilfe des Azure DevOps-Erweiterungs-SDK an.

Hinweis

Pipelinedekortoren werden beim Erstellen von Weberweiterungen verwendet. Diese Beispiele sind nicht für die Arbeit in YAML-Pipelines konzipiert.

Ressourcen

Pipelineressourcen sind für das resources Objekt verfügbar.

Repositorys

Derzeit gibt es nur einen Schlüssel: repositories. repositories ist eine Zuordnung von Repository-ID zu Informationen zum Repository.

In einem Designerbuild lautet __designer_repoder primäre Repositoryalias . In einer YAML-Pipeline wird das primäre Repository aufgerufen self. In einer Releasepipeline sind Repositorys nicht verfügbar. Releaseartefaktevariablen sind verfügbar.

Um beispielsweise den Namen des self Repositorys in einer YAML-Pipeline zu drucken:

steps:
- script: echo ${{ resources.repositories['self'].name }}

Repositorys enthalten die folgenden Eigenschaften:

resources['repositories']['self'] =
{
	"alias": "self",
	"id": "<repo guid>",
	"type": "Git",
	"version": "<commit hash>",
	"name": "<repo name>",
	"project": "<project guid>",
	"defaultBranch": "<default ref of repo, like 'refs/heads/main'>",
	"ref": "<current pipeline ref, like 'refs/heads/topic'>",
	"versionInfo": {
		"author": "<author of tip commit>",
		"message": "<commit message of tip commit>"
	},
	"checkoutOptions": {}
}

Job

Auftragsdetails sind für das job Objekt verfügbar.

Die Daten sehen ähnlich wie folgt aus:

job = 
{
	"steps": [
		{
			"environment": null,
			"inputs": {
				"script": "echo hi"
			},
			"type": "Task",
			"task": {
				"id": "d9bafed4-0b18-4f58-968d-86655b4d2ce9",
				"name": "CmdLine",
				"version": "2.146.1"
			},
			"condition": null,
			"continueOnError": false,
			"timeoutInMinutes": 0,
			"id": "5c09f0b5-9bc3-401f-8cfb-09c716403f48",
			"name": "CmdLine",
			"displayName": "CmdLine",
			"enabled": true
		}
	]
}

So fügen Sie beispielsweise eine Aufgabe nur bedingt hinzu, wenn sie noch nicht vorhanden ist:

- ${{ if not(containsValue(job.steps.*.task.id, 'f3ab91e7-bed6-436a-b651-399a66fe6c2a')) }}:
  - script: echo conditionally inserted

Variablen

Pipelinevariablen sind ebenfalls verfügbar.

Wenn die Pipeline z. B. eine Variable aufgerufen myVarhat, wäre ihr Wert für den Dekorateur verfügbar als variables['myVar'].

Um beispielsweise einem Dekorateur eine Abmeldung zu geben, könnten wir nach einer Variablen suchen. Pipelineautoren, die sich vom Dekorateur abmelden möchten, können diese Variable festlegen, und der Dekorateur wird nicht injiziert. Wenn die Variable nicht vorhanden ist, wird der Dekorator wie gewohnt eingefügt.

my-decorator.yml

- ${{ if ne(variables['skipInjecting'], 'true') }}:
  - script: echo Injected the decorator

Anschließend kann der Autor in einer Pipeline in der Organisation den Dekorateur anfordern, sich nicht selbst injizieren zu lassen.

pipeline-with-opt-out.yml

variables:
  skipInjecting: true
steps:
- script: echo This is the only step. No decorator is added.

Aufgabennamen und GUIDs

Dekorateure werden ausgeführt, nachdem Aufgaben bereits in GUIDs umgewandelt wurden. Beachten Sie folgendes YAML:

steps:
- checkout: self
- bash: echo This is the Bash task
- task: PowerShell@2
  inputs:
    targetType: inline
    script: Write-Host This is the PowerShell task

Jeder dieser Schritte ist einem Vorgang zugeordnet. Jede Aufgabe verfügt über eine eindeutige GUID. Aufgabennamen und Schlüsselwörter werden aufgaben-GUIDs zugeordnet, bevor Dekorateure ausgeführt werden. Wenn ein Dekorateur nach dem Vorhandensein einer anderen Aufgabe suchen möchte, muss er nach Aufgaben-GUID und nicht nach Name oder Schlüsselwort suchen.

Bei normalen Aufgaben (die Sie mit dem task Schlüsselwort angeben) können Sie sich die GUID der Aufgabe task.json ansehen. Für spezielle Schlüsselwörter wie checkout und bash im vorherigen Beispiel können Sie die folgenden GUIDs verwenden:

Schlüsselwort	GUID	Aufgabenname
`checkout`	`6D15AF64-176C-496D-B583-FD2AE21D4DF4`	n/a, siehe Hinweis
`bash`	`6C731C3C-3C68-459A-A5C9-BDE6E6595B5B`	Bash
`script`	`D9BAFED4-0B18-4F58-968D-86655B4D2CE9`	CmdLine
`powershell`	`E213FF0F-5D5C-4791-802D-52EA3E7BE1F1`	PowerShell
`pwsh`	`E213FF0F-5D5C-4791-802D-52EA3E7BE1F1`	PowerShell
`publish`	`ECDC45F6-832D-4AD9-B52B-EE49E94659BE`	PublishPipelineArtifact
`download`	`30f35852-3f7e-4c0c-9a88-e127b4f97211`	DownloadPipelineArtifact

Nachdem Aufgabennamen und Schlüsselwörter aufgelöst wurden, wird das vorherige YAML zu:

steps:
- task: 6D15AF64-176C-496D-B583-FD2AE21D4DF4@1
  inputs:
    repository: self
- task: 6C731C3C-3C68-459A-A5C9-BDE6E6595B5B@3
  inputs:
    targetType: inline
    script: echo This is the Bash task
- task: E213FF0F-5D5C-4791-802D-52EA3E7BE1F1@2
  inputs:
    targetType: inline
    script: Write-Host This is the PowerShell task

Tipp

Sie finden jede dieser GUIDs in der task.json für den entsprechenden In-Box-Vorgang. Die einzige Ausnahme ist checkout, die eine systemeigene Funktion des Agents ist. Seine GUID ist in den Azure Pipelines-Dienst und -Agent integriert.

Freigeben über