Context van expressie voor pijplijn-decorator

Artikel
02/27/2024

Azure DevOps Services

Pijplijn-decorators hebben toegang tot context over de pijplijn waarin ze worden uitgevoerd. Als auteur van een pijplijn decorator kunt u deze context gebruiken om beslissingen te nemen over het gedrag van de decorator. De informatie die beschikbaar is in context, verschilt voor pijplijnen en voor release. Decorators worden ook uitgevoerd nadat taaknamen zijn omgezet in GUID's (Globally Unique Identifiers). Wanneer uw decorator naar een taak wil verwijzen, moet deze de GUID gebruiken in plaats van de naam of het trefwoord.

Tip

Bekijk onze nieuwste documentatie over uitbreidingsontwikkeling met behulp van de Azure DevOps Extension SDK.

Notitie

Pijplijn-decorators worden gebruikt bij het bouwen van webextensies. Deze voorbeelden zijn niet ontworpen voor gebruik in YAML-pijplijnen.

Resources

Pijplijnbronnen zijn beschikbaar op het resources object.

Opslagplaatsen

Op dit moment is er slechts één sleutel: repositories. repositories is een toewijzing van opslagplaats-id naar informatie over de opslagplaats.

In een ontwerpfunctie is de primaire opslagplaatsalias __designer_repo. In een YAML-pijplijn wordt de primaire opslagplaats aangeroepen self. In een release-pijplijn zijn opslagplaatsen niet beschikbaar. Releaseartefactvariabelen zijn beschikbaar.

Als u bijvoorbeeld de naam van de self opslagplaats wilt afdrukken in een YAML-pijplijn:

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

Opslagplaatsen bevatten deze eigenschappen:

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

Project

Taakdetails zijn beschikbaar voor het job object.

De gegevens zien er ongeveer als volgt uit:

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

Als u bijvoorbeeld een taak voorwaardelijk alleen wilt toevoegen als deze nog niet bestaat:

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

Variabelen

Pijplijnvariabelen zijn ook beschikbaar.

Als de pijplijn bijvoorbeeld een variabele had aangeroepen myVar, zou de waarde beschikbaar zijn voor de decorator als variables['myVar'].

Als u bijvoorbeeld een decorator een opt-out wilt geven, kunnen we zoeken naar een variabele. Auteurs van pijplijnen die zich willen afmelden voor de decorator, kunnen deze variabele instellen en de decorator wordt niet geïnjecteerd. Als de variabele niet aanwezig is, wordt de decorator zoals gewoonlijk geïnjecteerd.

my-decorator.yml

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

Vervolgens kan de auteur in een pijplijn in de organisatie de decorator vragen zichzelf niet te injecteren.

pipeline-with-opt-out.yml

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

Taaknamen en GUID's

Decorators worden uitgevoerd nadat taken al zijn omgezet in GUID's. Houd rekening met de volgende 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

Elk van deze stappen wordt toegewezen aan een taak. Elke taak heeft een unieke GUID. Taaknamen en trefwoorden worden toegewezen aan taak-GUID's voordat decorators worden uitgevoerd. Als een decorator wil controleren op het bestaan van een andere taak, moet deze zoeken op taak-GUID in plaats van op naam of trefwoord.

Voor normale taken (die u opgeeft met het task trefwoord), kunt u kijken naar de taak task.json om de BIJBEHORENDE GUID te bepalen. Voor speciale trefwoorden, zoals checkout en bash in het vorige voorbeeld, kunt u de volgende GUID's gebruiken:

Trefwoord	GUID	Naam van de taak
`checkout`	`6D15AF64-176C-496D-B583-FD2AE21D4DF4`	n/a, zie opmerking
`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

Nadat taaknamen en trefwoorden zijn omgezet, wordt de vorige 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

Tip

U vindt elk van deze GUID's in de task.json voor de bijbehorende taak in het vak. De enige uitzondering hierop is checkout, wat een systeemeigen mogelijkheid van de agent is. De GUID is ingebouwd in de Azure Pipelines-service en -agent.

Delen via