Contesto dell'espressione decorator della pipeline
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.
Nota
Gli elementi decorator della pipeline vengono usati durante la compilazione di estensioni Web. Questi esempi non sono progettati per funzionare nelle pipeline YAML.
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": {}
}
Mansione
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
Suggerimento
È possibile trovare ognuno di questi GUID nell'oggetto task.json
per l'attività in-box corrispondente.
L'unica eccezione è checkout
, che è una funzionalità nativa dell'agente.
Il GUID è integrato nel servizio Azure Pipelines e nell'agente.