Kontekst wyrażenia dekoratora potoku

Artykuł
11/09/2024

Azure DevOps Services

Dekoratory potoków mają dostęp do kontekstu dotyczącego potoku, w którym są uruchamiane. Jako autor dekoratora potoków możesz użyć tego kontekstu do podejmowania decyzji dotyczących zachowania dekoratora. Informacje dostępne w kontekście są różne dla potoków i wydania. Ponadto dekoratory są uruchamiane po rozpoznawaniu nazw zadań do zadań globalnie unikatowych identyfikatorów (GUID). Gdy dekorator chce odwoływać się do zadania, powinien używać identyfikatora GUID, a nie nazwy lub słowa kluczowego.

Napiwek

Zapoznaj się z naszą najnowszą dokumentacją dotyczącą programowania rozszerzeń przy użyciu zestawu SDK rozszerzenia usługi Azure DevOps.

Uwaga

Dekoratory potoków są używane podczas kompilowania rozszerzeń internetowych. Te przykłady nie są przeznaczone do pracy w potokach YAML.

Zasoby

Zasoby potoku resources są dostępne w obiekcie .

Repozytoria

Obecnie istnieje tylko jeden klucz: repositories. repositories jest mapą z identyfikatora repozytorium na informacje o repozytorium.

W kompilacji projektanta alias podstawowego repozytorium to __designer_repo. W potoku YAML repozytorium podstawowe nosi nazwę self. W potoku wydania repozytoria nie są dostępne. Dostępne są zmienne artefaktu wydania.

Aby na przykład wydrukować nazwę self repozytorium w potoku YAML:

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

Repozytoria zawierają następujące właściwości:

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

Zadanie

Szczegóły zadania są dostępne w job obiekcie .

Dane wyglądają podobnie do następujących:

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

Na przykład aby warunkowo dodać zadanie tylko wtedy, gdy jeszcze nie istnieje:

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

Zmienne

Dostępne są również zmienne potoku.

Jeśli na przykład potok miał zmienną o nazwie myVar, jego wartość będzie dostępna dla dekoratora jako variables['myVar'].

Na przykład aby nadać dekoratorowi rezygnację, możemy wyszukać zmienną. Autorzy potoków, którzy chcą zrezygnować z dekoratora, mogą ustawić tę zmienną, a dekorator nie jest wstrzykiwany. Jeśli zmienna nie jest obecna, dekorator jest wstrzykiwany jak zwykle.

my-decorator.yml

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

Następnie w potoku w organizacji autor może zażądać, aby dekorator nie wstrzyknął się.

pipeline-with-opt-out.yml

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

Nazwy zadań i identyfikatory GUID

Dekoratory są uruchamiane po tym, jak zadania są już zamieniane w identyfikatory GUID. Rozważmy następujący kod 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

Każdy z tych kroków jest mapowy na zadanie. Każde zadanie ma unikatowy identyfikator GUID. Nazwy zadań i słowa kluczowe są mapowane na identyfikatory GUID zadań przed uruchomieniem dekoratorów. Jeśli dekorator chce sprawdzić istnienie innego zadania, musi wyszukiwać według identyfikatora GUID zadania, a nie według nazwy lub słowa kluczowego.

W przypadku normalnych zadań (określonych za pomocą słowa kluczowego task ) można przyjrzeć się zadaniu task.json w celu określenia jego identyfikatora GUID. W przypadku specjalnych słów kluczowych, takich jak checkout i bash w poprzednim przykładzie, można użyć następujących identyfikatorów GUID:

Słowo kluczowe	Identyfikator GUID	Nazwa zadania
`checkout`	`6D15AF64-176C-496D-B583-FD2AE21D4DF4`	n/a, zobacz notatkę
`bash`	`6C731C3C-3C68-459A-A5C9-BDE6E6595B5B`	Bash
`script`	`D9BAFED4-0B18-4F58-968D-86655B4D2CE9`	Wiersz polecenia
`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

Po rozpoznaniu nazw zadań i słów kluczowych poprzedni kod YAML staje się:

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

Napiwek

Każdy z tych identyfikatorów GUID można znaleźć w task.json pliku dla odpowiedniego zadania w polu. Jedynym wyjątkiem jest checkout, czyli natywna funkcja agenta. Jego identyfikator GUID jest wbudowany w usługę Azure Pipelines i agenta.

Udostępnij za pośrednictwem