Контекст выражения декоратора конвейера

Статья
11/09/2024

Azure DevOps Services

Декораторы конвейеров имеют доступ к контексту о конвейере, в котором они выполняются. В качестве автора декоратора конвейера вы можете использовать этот контекст для принятия решений о поведении декоратора. Сведения, доступные в контексте, отличаются для конвейеров и выпуска. Кроме того, декораторы выполняются после разрешения имен задач для глобально уникальных идентификаторов задач (GUID). Если декоратор хочет ссылаться на задачу, он должен использовать GUID, а не имя или ключевое слово.

Совет

Ознакомьтесь с нашей новой документацией по разработке расширений с помощью пакета SDK для расширений Azure DevOps.

Примечание.

Декораторы конвейера используются при создании веб-расширений. Эти примеры не предназначены для работы в конвейерах YAML.

Ресурсы

Ресурсы конвейера доступны в объекте resources .

Репозитории

В настоящее время существует только один ключ: repositories repositories — это сопоставление из идентификатора репозитория с сведениями о репозитории.

В сборке конструктора основной псевдоним репозитория — __designer_repoэто . В конвейере YAML основной репозиторий называется self. В конвейере выпуска репозитории недоступны. Доступны переменные артефакта выпуска.

Например, чтобы распечатать имя репозитория self в конвейере YAML:

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

Репозитории содержат следующие свойства:

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 доступны для объекта.

Данные выглядят примерно так:

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

Например, чтобы условно добавить задачу, только если она еще не существует:

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

Переменные

Кроме того, доступны переменные конвейера.

Например, если конвейер имел переменную myVar, ее значение будет доступно декоратору как variables['myVar'].

Например, чтобы дать декоратору отказ, мы могли бы искать переменную. Авторы конвейера, желающие отказаться от декоратора, могут задать эту переменную, и декоратор не внедряется. Если переменная отсутствует, то декоратор внедряется как обычно.

my-decorator.yml

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

Затем в конвейере в организации автор может запросить декоратора не внедрять себя.

pipeline-with-opt-out.yml

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

Имена задач и идентификаторы GUID

Декораторы выполняются после того, как задачи уже превратились в графические идентификаторы. Рассмотрим следующий 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

Каждый из этих шагов сопоставляется с задачей. Каждая задача имеет уникальный GUID. Имена задач и ключевые слова сопоставляются с идентификаторами GUID задач перед выполнением декораторов. Если декоратор хочет проверить наличие другой задачи, он должен выполнять поиск по GUID задачи, а не по имени или ключевому слову.

Для обычных задач (которые указываются с помощью ключевого task слова), можно посмотреть на задачи task.json , чтобы определить его GUID. Для специальных ключевых слов, таких как checkout и bash в предыдущем примере, можно использовать следующие идентификаторы GUID:

Ключевое слово	GUID	Имя задачи
`checkout`	`6D15AF64-176C-496D-B583-FD2AE21D4DF4`	n/a, см. примечание
`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

После разрешения имен задач и ключевых слов предыдущий YAML становится следующим:

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

Совет

Каждый из этих графических идентификаторов можно найти в task.json поле для соответствующей задачи в поле. Единственное исключение — это checkoutсобственная возможность агента. Его GUID встроен в службу и агент Azure Pipelines.

Поделиться через