Contesto dell'espressione decorator della pipeline

Articolo
02/29/2024

Servizi di Azure DevOps

Gli elementi decorator della pipeline hanno accesso al contesto sulla pipeline in cui vengono eseguiti. In qualità di autore dell'elemento decorator della pipeline, è possibile usare questo contesto per prendere decisioni sul comportamento dell'elemento Decorator. Le informazioni disponibili nel contesto sono diverse per le pipeline e per il rilascio. Inoltre, i decorator vengono eseguiti dopo che i nomi delle attività vengono risolti in identificatori univoci globali (GUID). Quando l'elemento Decorator vuole fare riferimento a un'attività, deve usare il GUID anziché il nome o la parola chiave.

Suggerimento

Vedere la documentazione più recente sullo sviluppo di estensioni con Azure DevOps Extension SDK.

Risorse

Le risorse della pipeline sono disponibili nell'oggetto resources .

Repository

Attualmente è presente una sola chiave: repositories. repositories è una mappa dall'ID repository alle informazioni sul repository.

In una compilazione della finestra di progettazione, l'alias del repository primario è __designer_repo. In una pipeline YAML il repository primario è denominato self. In una pipeline di versione i repository non sono disponibili. Sono disponibili variabili dell'artefatto di versione.

Ad esempio, per stampare il nome del self repository in una pipeline YAML:

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

I repository contengono queste proprietà:

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": {}
}

Posizione

I dettagli del processo sono disponibili nell'oggetto job .

I dati hanno un aspetto simile al seguente:

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
		}
	]
}

Ad esempio, per aggiungere in modo condizionale un'attività solo se non esiste già:

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

Variabili

Sono disponibili anche variabili della pipeline.

Ad esempio, se la pipeline aveva una variabile denominata myVar, il relativo valore sarebbe disponibile per l'elemento Decorator come variables['myVar'].

Ad esempio, per assegnare un elemento decorator un rifiuto esplicito, è possibile cercare una variabile. Gli autori della pipeline che desiderano rifiutare esplicitamente l'elemento Decorator possono impostare questa variabile e l'elemento decorator non viene inserito. Se la variabile non è presente, l'elemento Decorator viene inserito come di consueto.

my-decorator.yml

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

Quindi, in una pipeline nell'organizzazione, l'autore può richiedere all'elemento decorator di non inserire se stesso.

pipeline-with-opt-out.yml

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

Nomi e GUID delle attività

Gli elementi Decorator vengono eseguiti dopo che le attività sono già state trasformate in GUID. Si consideri il codice YAML seguente:

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

Ognuno di questi passaggi esegue il mapping a un'attività. Ogni attività ha un GUID univoco. I nomi delle attività e le parole chiave eseguono il mapping ai GUID delle attività prima dell'esecuzione degli elementi Decorator. Se un elemento Decorator vuole verificare l'esistenza di un'altra attività, deve eseguire la ricerca in base al GUID dell'attività anziché in base al nome o alla parola chiave.

Per le normali attività (specificate con la task parola chiave ), è possibile esaminare il GUID dell'attività task.json . Per parole chiave speciali come checkout e bash nell'esempio precedente, è possibile usare i GUID seguenti:

Parola chiave	GUID	Nome attività
`checkout`	`6D15AF64-176C-496D-B583-FD2AE21D4DF4`	n/a, vedere la nota
`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

Dopo la risoluzione dei nomi e delle parole chiave delle attività, il file YAML precedente diventa:

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