Condividi tramite

Risorse nelle pipeline YAML

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Questo articolo illustra le risorse per le pipeline YAML. Una risorsa è qualsiasi elemento usato da una pipeline esistente all'esterno della pipeline. Dopo aver definito una risorsa, è possibile usarla in qualsiasi punto della pipeline.

Le risorse offrono la tracciabilità completa per i servizi usati dalla pipeline, tra cui la versione, gli artefatti, i commit associati e gli elementi di lavoro. È possibile automatizzare completamente i flussi di lavoro devOps sottoscrivendo per attivare eventi sulle risorse.

Schema delle risorse

Le risorse in YAML rappresentano origini di pipeline, compilazioni, repository, contenitori, pacchetti e webhook. Per informazioni complete sullo schema, vedere la definizione delle risorse nella guida di riferimento allo schema YAML per Azure Pipelines.

Quando una risorsa attiva una pipeline, vengono impostate le variabili seguenti:

resources.triggeringAlias
resources.triggeringCategory

La variabile Build.Reason deve essere ResourceTrigger per questi valori da impostare. I valori sono vuoti se una risorsa non ha attivato l'esecuzione della pipeline.

Definizione risorsa della Pipeline

Se si dispone di una pipeline che produce artefatti, è possibile utilizzare gli artefatti definendo una pipelines risorsa. Solo Azure Pipelines può usare la pipelines risorsa. È possibile impostare i trigger per i flussi di lavoro di distribuzione continua (CD) in una risorsa della pipeline.

Nella definizione della risorsa, pipeline è un valore univoco che è possibile utilizzare per fare riferimento alla risorsa pipeline successivamente. source è il nome della pipeline che ha generato l'artefatto. Per informazioni complete sullo schema, vedere la definizione resources.pipelines.pipeline.

Usare l'etichetta definita da pipeline per riferirsi alla risorsa della pipeline da altre parti della pipeline, ad esempio quando si utilizzano le variabili di risorsa della pipeline o si scaricano artefatti. Per un'alternativa per scaricare gli artefatti della pipeline, vedere Download artifacts.

Importante

Quando si definisce un trigger di risorsa della pipeline:

  • Se la pipeline risorsa proviene dallo stesso repository della pipeline corrente o self, l'attivazione segue lo stesso ramo e il commit in cui viene generato l'evento.
  • Se la risorsa della pipeline proviene da un altro repository, la pipeline corrente viene attivata sul ramo predefinito del repository di risorse pipeline.

Definizioni di risorse della pipeline di esempio

Nell'esempio seguente vengono consumati artefatti da una pipeline nello stesso progetto.

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

Per utilizzare una pipeline da un altro progetto, includere il nome del progetto e il nome dell'origine. L'esempio seguente usa branch per risolvere la versione predefinita quando la pipeline viene attivata manualmente o pianificata. L'input del ramo non può contenere caratteri jolly.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

L'esempio seguente illustra una risorsa della pipeline con un trigger semplice.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger: true

L'esempio seguente mostra una risorsa trigger della pipeline con condizioni sui rami.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

Nell'esempio seguente vengono usati filtri stages per valutare le condizioni di trigger per le pipeline CD. Le fasi usano l'operatore AND . Al termine con successo di tutte le fasi fornite, la pipeline CD viene attivata.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

Nell'esempio seguente vengono usati i filtri tags per la valutazione della versione predefinita e per i trigger. I tag usano l'operatore AND .

tags sono impostati nella pipeline di integrazione continua (CI) o distribuzione continua (CD). Questi tag differiscono dai tag impostati nei rami nel repository Git.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

Valutazione della versione degli artefatti delle pipeline

La versione dell'artefatto della pipeline di risorse dipende dalla modalità di attivazione della pipeline.

Attivazione manuale o pianificata

Se l'esecuzione della pipeline viene attivata manualmente o pianificata, i valori delle proprietà version, branch, e tags definiscono la versione dell'artefatto. L'input branch non può avere caratteri jolly. Le tags proprietà usano l'operatore AND .

Proprietà specificate Versione dell'artefatto
version Gli artefatti della compilazione che hanno il numero di esecuzione specificato
branch Artefatti della build più recente eseguita nel ramo specificato
tags lista Artefatti della build più recente con tutti i tag specificati
branch e tags elenco Gli artefatti dell'ultima build eseguita nel ramo specificato con tutti i tag indicati.
version e branch Risultati della compilazione con il numero di esecuzione specificato e il ramo specificato.
None Artefatti della build più recente attraverso tutti i rami

La definizione di risorsa seguente pipeline usa le branch proprietà e tags per valutare la versione predefinita quando la pipeline viene attivata manualmente o pianificata. Quando si attiva manualmente la pipeline per l'esecuzione, la versione degli artefatti della MyCIAlias pipeline è l'ultima build eseguita nel branch main con i tag Production e PrepProduction.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

Trigger di completamento della pipeline di risorse

Quando una pipeline viene attivata a causa del completamento di una delle sue pipeline di risorse, la versione degli artefatti è la versione della pipeline che ha innescato il processo. I valori delle versionproprietà , branche tags vengono ignorati.

Trigger specificati Risultato
branches Un nuovo trigger di esecuzione della pipeline si attiva ogni volta che la pipeline di risorse completa correttamente un'esecuzione in uno dei branch include.
tags Un nuovo trigger di esecuzione della pipeline ogni volta che la pipeline di risorse completa correttamente un'esecuzione contrassegnata con tutti i tag specificati.
stages Una nuova esecuzione della pipeline viene avviata ogni volta che la pipeline di risorse esegue con successo l'oggetto specificato stages.
branches, tags e stages Una nuova esecuzione della pipeline viene attivata ogni volta che l'esecuzione della pipeline di risorse soddisfa tutte le condizioni di ramo, tag e fasi.
trigger: true Una nuova esecuzione della pipeline viene avviata ogni volta che la pipeline delle risorse completa correttamente un'esecuzione.
Niente Nessun nuovo trigger di esecuzione della pipeline quando la pipeline di risorse completa correttamente un'esecuzione.

La pipeline seguente viene eseguita ogni volta che la pipeline di SmartHotel-CI risorse:

  • Viene eseguito in uno dei releases rami o nel main ramo
  • È contrassegnato con entrambi Verified e Signed
  • Completa sia la fase Production che la fase PreProduction
resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Scaricamento dell'artefatto dalla pipeline

Il passaggio download scarica gli artefatti collegati alla corsa corrente o a un'altra risorsa della pipeline.

Tutti gli artefatti della pipeline corrente e tutte le relative pipeline risorse vengono scaricati e resi disponibili automaticamente all'inizio di ogni processo di distribuzione. È possibile eseguire l'override di questo comportamento impostando download su noneo specificando un altro identificatore di risorsa della pipeline.

Gli artefatti di lavoro normali non vengono scaricati automaticamente. Usare download in modo esplicito quando necessario.

Gli artefatti della pipeline risorsa vengono scaricati in $(PIPELINE. WORKSPACE)/<pipeline-identifier>/<artifact-identifier> cartella. Per altre informazioni, vedere Pubblica e scarica artefatti della pipeline.

La proprietà facoltativa artifact specifica i nomi degli artefatti. Se non specificato, vengono scaricati tutti gli artefatti disponibili. La proprietà facoltativa patterns definisce i modelli che rappresentano i file da includere. Per informazioni complete sullo schema, vedere la definizione steps.download.

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

Variabili delle risorse della pipeline

In ogni esecuzione, i metadati per una risorsa della pipeline sono disponibili per tutti i processi come variabili predefinite. Queste variabili sono disponibili solo per la pipeline in fase di esecuzione e pertanto non possono essere usate nelle espressioni modello, che vengono valutate in fase di compilazione della pipeline.

Per altre informazioni, vedere Metadati delle risorse della pipeline come variabili predefinite. Per altre informazioni sulla sintassi delle variabili, vedere Definire le variabili.

Nell'esempio seguente vengono restituiti i valori di variabile predefiniti per la myresourcevars risorsa della pipeline.

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

Compila la definizione di risorsa

Se si dispone di un sistema di compilazione CI esterno che produce artefatti, è possibile gestire questi artefatti con le risorse builds. Una build risorsa può essere da qualsiasi sistema CI esterno, ad esempio Jenkins, TeamCity o CircleCI.

La builds categoria è estendibile. È possibile scrivere un'estensione per integrare artefatti dal servizio di build e introdurre un nuovo tipo di servizio come parte di builds.

Nella definizione build, il version valore predefinito è la build riuscita più recente. Non è abilitato per impostazione predefinita e deve essere specificato esplicitamente. Per informazioni complete sullo schema, vedere la definizione di resources.builds.build.

Nell'esempio seguente Jenkins è la risorsa type.

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

Importante

I trigger sono supportati solo per i Jenkins ospitati dove Azure DevOps ha visibilità diretta sul server Jenkins.

Attività downloadBuild

Gli artefatti delle risorse non vengono scaricati automaticamente nei jobs/deploy-jobs. Per utilizzare gli artefatti dalla risorsa build come parte dei tuoi incarichi, è necessario aggiungere esplicitamente l'attività downloadBuild. È possibile personalizzare il comportamento di download per ogni distribuzione o processo.

Questa attività viene risolta automaticamente nell'attività di download corrispondente per il tipo di build risorsa definita dal runtime. Gli artefatti della build risorsa vengono scaricati in $(PIPELINE. WORKSPACE)/<build-identifier>/ folder.

downloadBuild Nella definizione specificare la risorsa da cui scaricare gli artefatti. La proprietà facoltativa artifact specifica gli artefatti da scaricare. Se non specificato, vengono scaricati tutti gli artefatti associati alla risorsa.

La proprietà facoltativa patterns definisce un percorso o un elenco di percorsi minimatch da scaricare. Se lasciato vuoto, viene scaricato l'intero oggetto. Ad esempio, il frammento di codice seguente scarica solo i file *.zip .

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

Per informazioni complete sullo schema, vedere la definizione steps.downloadBuild.

Definizione della risorsa del repository

La repository parola chiave consente di specificare un repository esterno. È possibile utilizzare questa risorsa se la tua pipeline include modelli in un altro repository o se desideri utilizzare il checkout multi-repo con un repository che richiede una connessione di servizio. È necessario informare il sistema di questi repository.

Ad esempio:

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

Per informazioni complete sullo schema, vedere la definizione di resources.repositories.repository.

Tipi di risorse del repository

Azure Pipelines supporta i valori seguenti per il tipo di repository: git, githubgithubenterprise, e bitbucket.

  • Il git tipo fa riferimento ai repository Git di Azure Repos.
  • I repository GitHub Enterprise richiedono una connessione al servizio GitHub Enterprise per l'autorizzazione.
  • I repository di Bitbucket Cloud richiedono una connessione al servizio cloud Bitbucket per l'autorizzazione.
Tipo Nome del valore Esempio
type: git Un altro repository nello stesso progetto o nella stessa organizzazione. Stesso progetto: name: otherRepo
Un altro progetto nella stessa organizzazione: name: otherProject/otherRepo.
type: github Nome completo del repository GitHub, incluso l'utente o l'organizzazione. name: Microsoft/vscode
type: githubenterprise Nome completo del repository GitHub Enterprise, incluso l'utente o l'organizzazione. name: Microsoft/vscode
type: bitbucket Nome completo del repository Bitbucket Cloud, incluso l'utente o l'organizzazione. name: MyBitbucket/vscode

Variabili delle risorse del repository

In ogni esecuzione, i metadati seguenti per una risorsa del repository sono disponibili per tutti i processi sotto forma di variabili di runtime. <Alias> è l'identificatore che si assegna alla risorsa del repository.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url

Nell'esempio seguente è presente una risorsa del repository con un alias , commonin modo che le variabili di risorsa del repository siano accessibili usando resources.repositories.common.*.

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"

In ogni esecuzione, i metadati seguenti per una risorsa del repository sono disponibili per tutti i processi sotto forma di variabili di runtime. <Alias> è l'identificatore che si assegna alla risorsa del repository.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
resources.repositories.<Alias>.version

Nell'esempio seguente è presente una risorsa del repository con un alias , commonin modo che le variabili di risorsa del repository siano accessibili usando resources.repositories.common.*.

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

Parola chiave Checkout per i repository

I repository dalla repository risorsa non vengono sincronizzati automaticamente nelle attività. Usare la checkout parola chiave per recuperare un repository definito come parte della repository risorsa. Per informazioni complete sullo schema, vedere la definizione steps.checkout.

Per altre informazioni, vedere Consultare più repository nella pipeline.

Definizione della risorsa dei contenitori

Se è necessario usare le immagini del contenitore come parte delle pipeline CI/CD, è possibile usare le containers risorse. Una container risorsa può essere un registro Docker pubblico o privato o un'istanza di Registro Azure Container.

È possibile usare un'immagine di risorsa contenitore generica come parte del tuo lavoro, o usare la risorsa per i job dei container. Se la pipeline richiede il supporto di uno o più servizi, è necessario creare e connettersi ai contenitori del servizio. È possibile usare i volumi per condividere i dati tra i servizi.

Se è necessario usare immagini da un registro Docker come parte della pipeline, è possibile definire una risorsa contenitore generica. Non è necessaria alcuna type parola chiave. Ad esempio:

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp

Per informazioni complete sullo schema, vedere la definizione resources.containers.container.

Nota

La enabled: 'true' sintassi per abilitare i trigger del contenitore per tutti i tag di immagine è diversa dalla sintassi per altri trigger di risorse. Assicurarsi di usare la sintassi corretta per risorse specifiche.

Tipo di risorsa del Registro Azure Container

Per usare le immagini del Registro Azure Container, è possibile utilizzare il tipo risorsa contenitore di prima classe acr. È possibile usare questo tipo di risorsa come parte degli incarichi e per attivare automaticamente i trigger della pipeline.

Sono necessarie autorizzazioni di collaboratore o proprietario del Registro Azure Container per l'uso degli attivatori automatici della pipeline. Per altre informazioni, vedere Ruoli e autorizzazioni di Registro Azure Container.

Per usare il acr tipo di risorsa, è necessario specificare i azureSubscriptionvalori , resourceGroupe repository per il Registro Azure Container. Ad esempio:

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production*

Nota

La valutazione del trigger si verifica solo nel ramo predefinito. Assicurarsi di impostare il ramo predefinito corretto o di unire il file YAML nel ramo predefinito corrente. Per altre informazioni su come modificare il ramo predefinito della pipeline, vedere Il ramo predefinito della pipeline.

Variabili delle risorse del contenitore

Dopo aver definito un contenitore come risorsa, i metadati dell'immagine del contenitore passano alla pipeline come variabili. Le informazioni come immagine, registro e dettagli di connessione sono accessibili in tutti i processi usati nelle attività di distribuzione del contenitore.

Le variabili delle risorse del contenitore funzionano con Docker e Registro Azure Container. Non è possibile usare le variabili delle risorse del contenitore per i contenitori di immagini locali. La location variabile si applica solo al acr tipo di risorse del contenitore.

L'esempio seguente ha una connessione al servizio Azure Resource Manager denominata arm-connection. Per altre informazioni, vedere Registri, repository e immagini dei contenitori di Azure.

resources:
  containers:
  - container: mycontainer
    type: ACR
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

Definizione della risorsa pacchetto software

È possibile usare pacchetti GitHub NuGet e npm come risorse nelle pipeline YAML. Per abilitare i trigger automatizzati della pipeline quando viene rilasciata una nuova versione del pacchetto, impostare la trigger proprietà su true.

Quando si definiscono le risorse package, specificare il pacchetto <Repository>/<Name> nella proprietà name, e impostare il pacchetto type come NuGet o npm. Per usare i pacchetti GitHub, usare l'autenticazione basata su token di accesso personale e creare una connessione al servizio GitHub che usa il token di accesso personale.

Per informazioni complete sullo schema, vedere la definizione resources.packages.package.

Per impostazione predefinita, i pacchetti non vengono scaricati automaticamente nei processi. Per scaricare, usare getPackage.

L'esempio seguente include una connessione al servizio GitHub denominata pat-contoso a un pacchetto npm GitHub denominato contoso. Per altre informazioni, vedere Pacchetti GitHub.

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

La definizione della risorsa webhooks

Nota

I webhook sono stati rilasciati in Azure DevOps Server 2020.1.

È possibile consumare artefatti e abilitare i trigger automatizzati con risorse di pipeline, container, build e pacchetto. Tuttavia, non è possibile usare queste risorse per automatizzare le distribuzioni in base a eventi o servizi esterni.

La webhooks risorsa nelle pipeline YAML consente di integrare le pipeline con servizi esterni come GitHub, GitHub Enterprise, Nexus e Artifactory per automatizzare i flussi di lavoro. È possibile sottoscrivere qualsiasi evento esterno tramite webhook e usare gli eventi per attivare le pipeline.

I webhook automatizzano il flusso di lavoro in base a qualsiasi evento webhook esterno non supportato da risorse di prima classe come pipeline, compilazioni, contenitori o pacchetti. Inoltre, per i servizi locali in cui Azure DevOps non ha visibilità sul processo, è possibile configurare webhook nel servizio e attivare automaticamente le pipeline.

Per sottoscrivere un evento webhook, è necessario definire una risorsa webhook nella pipeline e indirizzarla verso una connessione al servizio webhook in ingresso. È anche possibile definire altri filtri sulla risorsa webhook, in base ai dati del payload JSON, per personalizzare i trigger per ogni pipeline.

Ogni volta che la connessione al servizio webhook in ingresso riceve un evento webhook, viene avviata una nuova esecuzione per tutte le pipeline sottoscritte all'evento webhook. È possibile usare i dati del payload JSON nei processi come variabili usando il formato ${{ parameters.<WebhookAlias>.<JSONPath>}}.

Per informazioni complete sullo schema, vedere la definizione resources.webhooks.webhook.

L'esempio seguente definisce una risorsa webhook:

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

steps:  
- script: echo ${{ parameters.WebHook.resource.message.title }}

Trigger webhook

Per configurare i trigger webhook, è prima necessario configurare un webhook nel servizio esterno, fornendo le informazioni seguenti:

  • URL richiesta: https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
  • Segreto (facoltativo): se è necessario proteggere il payload JSON, specificare un valore segreto.

Successivamente, si crea una nuova connessione al servizio webhook in ingresso. Per questo tipo di connessione al servizio, definire le informazioni seguenti:

  • Nome WebHook: Lo stesso del webhook creato nel servizio esterno.
  • Segreto (facoltativo): usato per verificare l'hash HMAC-SHA1 del payload per la verifica della richiesta in ingresso. Se è stato usato un segreto durante la creazione del webhook, è necessario fornire lo stesso segreto.
  • Intestazione HTTP: nella richiesta l'intestazione HTTP, che contiene il valore hash HMAC-SHA1 del payload per la verifica della richiesta. Ad esempio, l'intestazione della richiesta GitHub è X-Hub-Signature.

Screenshot che mostra la connessione al servizio webhook in ingresso.

Per attivare la pipeline usando un webhook, effettuare una POST richiesta a https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Questo endpoint è disponibile pubblicamente e non richiede alcuna autorizzazione. La richiesta deve avere un corpo simile all'esempio seguente:

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

Nota

L'accesso ai dati dal corpo della richiesta del webhook può causare errori YAML. Ad esempio, il passaggio - script: echo ${{ parameters.WebHook.resource.message }} della pipeline esegue il pull dell'intero messaggio JSON, che genera YAML non valido. Qualsiasi pipeline attivata tramite questo webhook non viene eseguita perché il file YAML generato non è valido.

Il frammento di codice seguente mostra un altro esempio che usa filtri webhook.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

Selezione della versione manuale per le risorse

Quando si attiva manualmente una pipeline YAML cd, Azure Pipelines valuta automaticamente le versioni predefinite per le risorse definite nella pipeline, in base agli input forniti. Tuttavia, Azure Pipelines considera le esecuzioni di integrazione continua completate solo quando si valuta la versione predefinita per i trigger pianificati o se non si sceglie manualmente una versione.

È possibile usare la selezione della versione della risorsa per scegliere manualmente una versione diversa quando si crea un'esecuzione. La selezione della versione delle risorse è supportata per le risorse della pipeline, della compilazione, del repository, del contenitore e del pacchetto.

Per le risorse della pipeline, è possibile visualizzare tutte le esecuzioni disponibili in tutti i rami, cercarle in base al numero o al ramo della pipeline e selezionare un'esecuzione riuscita, non riuscita o in corso. Questa flessibilità garantisce che sia possibile eseguire la pipeline CD se si è certi che un'operazione abbia prodotto tutti gli artefatti necessari. Non è necessario attendere il completamento di un processo CI, né eseguirlo nuovamente a causa di un errore in una fase non correlata.

Per usare la selezione della versione della risorsa, nel riquadro Esegui pipeline selezionare Risorse, quindi selezionare una risorsa e selezionare una versione specifica dall'elenco delle versioni disponibili.

Screenshot che mostra il selettore di versione delle risorse del repository.

Per le risorse in cui non è possibile recuperare le versioni disponibili, ad esempio i pacchetti GitHub, la selezione versione fornisce un campo di testo in modo da poter immettere la versione da selezionare per l'esecuzione.

Autorizzazione delle risorse nelle pipeline YAML

Le risorse devono essere autorizzate prima di poterle usare nelle pipeline. I proprietari delle risorse controllano gli utenti e le pipeline che possono accedere alle risorse. Esistono diversi modi per autorizzare una pipeline YAML a usare le risorse.

  • Usare l'esperienza di amministrazione delle risorse per autorizzare tutte le pipeline ad accedere alla risorsa. Ad esempio, i gruppi di variabili e i file sicuri vengono gestiti nella pagina Libreria in Pipeline e i pool di agenti e le connessioni al servizio vengono gestiti nelle impostazioni di Project. Questa autorizzazione è utile se non è necessario limitare l'accesso alle risorse, ad esempio per le risorse di test.

  • Quando si crea una pipeline, tutte le risorse a cui si fa riferimento nel file YAML vengono autorizzate automaticamente per l'uso dalla pipeline se si ha il ruolo Utente per tali risorse.

  • Se si aggiunge una risorsa a un file YAML e la compilazione ha esito negativo con un errore simile Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.a , viene visualizzata un'opzione per autorizzare le risorse nella compilazione non riuscita.

    Se sei membro del ruolo Utente per la risorsa, puoi selezionare questa opzione e autorizzare la risorsa nella build non riuscita. Dopo aver autorizzato la risorsa, è possibile avviare una nuova compilazione.

  • Verificare che i ruoli di sicurezza del pool di agenti per il progetto siano corretti.

Controlli di approvazione per le risorse

È possibile usare controlli e modelli di approvazione per controllare manualmente quando viene eseguita una risorsa. Con il controllo di approvazione del modello necessario, è possibile richiedere che qualsiasi pipeline che usi una risorsa o un ambiente si estenda da un modello YAML specifico.

L'impostazione di un'approvazione del modello necessaria garantisce che la risorsa venga usata solo in condizioni specifiche e migliora la sicurezza. Per altre informazioni su come migliorare la sicurezza della pipeline con i modelli, vedere Usare i modelli per la sicurezza.

Tracciabilità

Azure Pipelines offre la tracciabilità completa per qualsiasi risorsa utilizzata a livello di processo di pipeline o distribuzione.

Tracciabilità delle pipeline

Azure Pipelines mostra le informazioni seguenti per ogni esecuzione della pipeline:

  • Se una risorsa ha attivato la pipeline, è la risorsa che l'ha fatto.
  • Versione della risorsa e artefatti utilizzati.
  • Commit associati con ogni risorsa.
  • Elementi di lavoro associati a ogni risorsa.

Tracciabilità dell'ambiente

Ogni volta che una pipeline viene distribuita in un ambiente, è possibile visualizzare un elenco di risorse utilizzate. La vista include le risorse utilizzate come parte dei processi di distribuzione e i commit e gli elementi di lavoro associati.

Screenshot che mostra i commit in un ambiente di sviluppo.

Informazioni sulle pipeline CD associate all'interno delle pipeline CI

Per fornire la tracciabilità end-to-end, è possibile tenere traccia delle pipeline CD che utilizzano una specifica pipeline CI tramite la risorsa pipelines. Se altre pipeline consumano la pipeline CI, viene visualizzata una scheda Pipeline associata nella visualizzazione esegui. La vista mostra tutte le esecuzioni delle pipeline YAML CD che hanno utilizzato la pipeline CI e i relativi artefatti.

Screenshot che mostra le informazioni sulle pipeline CD nelle pipeline CI.

Problemi relativi all'attivazione delle risorse

L'esecuzione dei trigger di risorse può non riuscire perché:

  • L'origine della connessione al servizio fornita non è valida, si verificano errori di sintassi nel trigger o il trigger non è configurato.
  • Le condizioni di attivazione non sono soddisfatte.

Per vedere perché l'esecuzione dei trigger della pipeline non è riuscita, selezionare la voce di menu Trigger issues nella pagina di definizione della pipeline. Problemi di trigger sono disponibili solo per le risorse non di repository.

Screenshot che mostra i problemi relativi ai trigger nella pagina principale della pipeline.

Nella pagina Problemi di trigger i messaggi di errore e di avviso descrivono il motivo per cui il trigger non è riuscito.

Screenshot che mostra la sostenibilità dei problemi di trigger.

Domande frequenti

Quando è consigliabile usare le risorse delle pipeline, il collegamento per il download o l'attività Scarica artefatti della pipeline?

L'impiego di una pipelines risorsa è un modo per consumare gli artefatti da una pipeline di integrazione continua e per configurare i trigger automatizzati. Una risorsa offre visibilità completa sul processo visualizzando la versione utilizzata, gli artefatti, i commit e gli elementi di lavoro. Quando si definisce una risorsa pipeline, gli artefatti associati vengono scaricati automaticamente nei processi di distribuzione.

È possibile utilizzare la download scorciatoia per scaricare gli artefatti nei processi di compilazione o per cambiare il comportamento di download nei processi di distribuzione. Per altre informazioni, vedere la definizione steps.download.

L'attività Scarica artefatti pipeline non fornisce tracciabilità o trigger, ma a volte ha senso usare direttamente questa attività. Ad esempio, potresti avere un'attività di script archiviata in un modello diverso che richiede il download degli artefatti da una build. In alternativa, potrebbe non essere necessario aggiungere una risorsa pipeline a un modello. Per evitare dipendenze, è possibile usare l'attività Download Pipeline Artifacts per trasferire tutte le informazioni del build a un'attività.

Come è possibile attivare un'esecuzione della pipeline quando l'immagine dell'hub Docker viene aggiornata?

Il trigger della risorsa del contenitore non è disponibile per l’hub Docker per le pipeline YAML, quindi è necessario configurare una pipeline di rilascio classica.

  1. Creare una nuova connessione al servizio Docker Hub.
  2. Creare una pipeline di rilascio classica e aggiungere un artefatto da Docker Hub. Impostare la connessione al servizio e selezionare lo spazio dei nomi, il repository, la versione e l'alias di origine.
  3. Selezionare il trigger e impostare il trigger di distribuzione continua su Abilita. Ogni push Docker che si verifica nel repository selezionato crea una versione.
  4. Creare una nuova fase e un nuovo processo. Aggiungere due attività, Docker login e Bash.
    • L'attività Docker ha l'azione login e accede all'hub Docker.
    • L'attività Bash esegue docker pull <hub-user>/<repo-name>[:<tag>].

Come è possibile convalidare e risolvere i problemi del webhook?

  1. Creare una connessione al servizio.

  2. Fare riferimento alla connessione al servizio e assegnare un nome al webhook nella sezione webhooks.

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Esegui la pipeline. Il webhook viene creato in Azure come attività distribuita per l'organizzazione.

  4. Eseguire una POST chiamata API con JSON valido nel corpo a https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Se si riceve una risposta con codice di stato 200, il webhook è pronto per essere utilizzato dalla pipeline.

Se si riceve una risposta di codice di stato 500 con l'errore Cannot find webhook for the given webHookId ..., il codice potrebbe trovarsi in un ramo che non è il ramo predefinito. Per risolvere questo problema:

  1. Selezionare Modifica nella pagina della pipeline.
  2. Scegliere Trigger dal menu Altre azioni.
  3. Selezionare la scheda YAML e quindi selezionare Recupera origini.
  4. Sotto Ramo predefinito per le compilazioni manuali e pianificate, aggiorna il tuo ramo delle funzionalità.
  5. Selezionare Salva e metti in coda.
  6. Dopo l'esecuzione con successo di questa pipeline, eseguire una POST chiamata API con JSON valido nel corpo a https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Si dovrebbe ora ricevere una risposta al codice di stato 200.

Contenuto correlato