Contexto de expresión del decorador de canalización

Artikulua
02/27/2024

Azure DevOps Services

Los decoradores de canalización tienen acceso al contexto sobre la canalización en la que se ejecutan. Como autor del decorador de canalización, puede usar este contexto para tomar decisiones sobre el comportamiento del decorador. La información disponible en contexto es diferente para las canalizaciones y para la versión. Además, los decoradores se ejecutan después de que los nombres de tarea se resuelvan en identificadores únicos globales de tareas (GUID). Cuando el decorador quiere hacer referencia a una tarea, debe usar el GUID en lugar del nombre o la palabra clave.

Sugerencia

Consulte nuestra documentación más reciente sobre el desarrollo de extensiones mediante el SDK de extensión de Azure DevOps.

Nota:

Los decoradores de canalización se usan al compilar extensiones web. Estos ejemplos no están diseñados para funcionar en canalizaciones YAML.

Recursos

Los recursos de canalización están disponibles en el resources objeto .

Repositorios

Actualmente, solo hay una clave: repositories. repositories es un mapa del identificador del repositorio a información sobre el repositorio.

En una compilación del diseñador, el alias del repositorio principal es __designer_repo. En una canalización YAML, el repositorio principal se denomina self. En una canalización de versión, los repositorios no están disponibles. Las variables de artefacto de versión están disponibles.

Por ejemplo, para imprimir el nombre del self repositorio en una canalización DE YAML:

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

Los repositorios contienen estas propiedades:

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

Trabajo

Los detalles del trabajo están disponibles en el job objeto .

Los datos tienen un aspecto similar al siguiente:

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

Por ejemplo, para agregar condicionalmente una tarea solo si aún no existe:

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

Variables

Las variables de canalización también están disponibles.

Por ejemplo, si la canalización tuviera una variable denominada myVar, su valor estaría disponible para el decorador como variables['myVar'].

Por ejemplo, para dar a un decorador una exclusión, podríamos buscar una variable. Los autores de canalizaciones que deseen no participar en el decorador pueden establecer esta variable y el decorador no se inserta. Si la variable no está presente, el decorador se inserta como de costumbre.

my-decorator.yml

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

A continuación, en una canalización de la organización, el autor puede solicitar al decorador que no se inserte a sí mismo.

pipeline-with-opt-out.yml

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

Nombres de tareas y GUID

Los decoradores se ejecutan después de las tareas ya convertidas en GUID. Tenga en cuenta lo siguiente:

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

Cada uno de esos pasos se asigna a una tarea. Cada tarea tiene un GUID único. Los nombres de tarea y las palabras clave se asignan a los GUID de tarea antes de que se ejecuten los decoradores. Si un decorador desea comprobar la existencia de otra tarea, debe buscar por GUID de tarea en lugar de por nombre o palabra clave.

En el caso de las tareas normales (que especifique con la task palabra clave ), puede examinar las tareas task.json para determinar su GUID. En el caso de palabras clave especiales como checkout y bash en el ejemplo anterior, puede usar los siguientes GUID:

Palabra clave	GUID	Nombre de tarea
`checkout`	`6D15AF64-176C-496D-B583-FD2AE21D4DF4`	n/a, consulte 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

Después de resolver los nombres de tarea y las palabras clave, yaML anterior se convierte en:

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

Sugerencia

Puede encontrar cada uno de estos GUID en para task.json la tarea integrada correspondiente. La única excepción es checkout, que es una funcionalidad nativa del agente. Su GUID está integrado en el servicio y el agente de Azure Pipelines.

Partekatu honen bidez: