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 della risorsa Pipelines

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 pipeline della risorsa è un valore univoco che è possibile usare per fare riferimento alla risorsa della pipeline in un secondo momento nella pipeline. source è il nome della pipeline che ha prodotto l'artefatto della pipeline. Per informazioni complete sullo schema, vedere la definizione resources.pipelines.pipeline.

Usare l'etichetta definita da pipeline per fare riferimento alla risorsa pipeline da altre parti della pipeline, ad esempio quando si usano variabili di risorsa della pipeline o si scaricano artefatti. Per un modo alternativo per scaricare gli artefatti della pipeline, vedere Scaricare gli artefatti.

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 repository diverso, la pipeline corrente viene attivata nel ramo predefinito del pipeline repository di risorse.

Definizioni di risorse della pipeline di esempio

Nell'esempio seguente vengono utilizzati artefatti da una pipeline all'interno dello 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ò avere 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 del ramo.

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 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 tags usati filtri per la valutazione della versione predefinita e per i trigger. I tag usano l'operatore AND .

Sono tags impostati nella pipeline di integrazione continua (CI) o 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 dell'artefatto pipeline

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

Trigger manuale o pianificato

Se l'esecuzione della pipeline viene attivata o pianificata manualmente, i valori delle versionproprietà , branche 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 Artefatti della compilazione con 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 Artefatti della build più recente eseguita nel ramo specificato con tutti i tag specificati
None Artefatti della build più recente in 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 è la build più recente eseguita nel main ramo con i Production tag 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 pipeline di risorse, la versione degli artefatti è la versione della pipeline di attivazione. I valori delle versionproprietà , branche tags vengono ignorati.

Trigger specificati Risultato
branches Un nuovo trigger di esecuzione della pipeline ogni volta che la pipeline di risorse completa correttamente un'esecuzione in uno dei include rami.
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 Un nuovo trigger di esecuzione della pipeline ogni volta che la pipeline di risorse esegue correttamente l'oggetto specificato stages.
branches, tags e stages Un nuovo trigger di esecuzione della pipeline ogni volta che la pipeline di risorse viene eseguita soddisfa tutte le condizioni di ramo, tag e fasi.
trigger: true Un nuovo trigger di esecuzione della pipeline ogni volta che la pipeline di risorse completa correttamente un'esecuzione.
Nothing 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
  • Tag con e VerifiedSigned
  • Completa entrambe le Production fasi e PreProduction
resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Download dell'artefatto della pipeline

Il download passaggio scarica gli artefatti associati all'esecuzione 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 processo 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 Pubblicare e scaricare gli 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 utilizzare gli artefatti con builds le risorse. 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 utilizzare gli artefatti dal servizio di compilazione e introdurre un nuovo tipo di servizio come parte di builds.

build Nella definizione il version valore predefinito è la build riuscita più recente. Non trigger è abilitato per impostazione predefinita e deve essere impostato in modo esplicito. Per informazioni complete sullo schema, vedere la definizione resources.build.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 per Jenkins ospitati solo in cui Azure DevOps ha una linea di visualizzazione con il server Jenkins.

Attività downloadBuild

Gli build artefatti delle risorse non vengono scaricati automaticamente nei processi o nei processi deploy-jobs. Per utilizzare gli artefatti dalla build risorsa come parte dei processi, è necessario aggiungere in modo esplicito 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 vuoto, viene scaricato l'intero artefatto. 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 usare questa risorsa se la pipeline include modelli in un altro repository o si vuole usare il checkout multi-repository con un repository che richiede una connessione al 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 resources.repository.repository.

Tipi di risorse del repository

Azure Pipelines supporta i valori seguenti per il tipo di repository: git, githubenterprisegithub, 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.
Type Valore nome 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 nei processi. 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 Estrazione di più repository nella pipeline.

Definizione di risorsa 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 processo o usare la risorsa per i processi del contenitore. 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.

Registro Azure Container tipo di risorsa

Per usare le immagini Registro Azure Container, è possibile usare il tipo di acrrisorsa contenitore di prima classe . È possibile usare questo tipo di risorsa come parte dei processi e per abilitare i trigger automatici della pipeline.

Sono necessarie autorizzazioni di collaboratore o proprietario per Registro Azure Container per l'uso dei trigger 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

Le connessioni al servizio che usano la federazione dell'identità del carico di lavoro non sono supportate in azureSubscription.

Variabili di risorsa 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 pacchetti

È 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 package le risorse, specificare il repository/<nome> del name pacchetto <>nella proprietà 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

Definizione di risorsa webhook

Nota

I webhook sono stati rilasciati in Azure DevOps Server 2020.1.

È possibile usare gli artefatti e abilitare trigger automatizzati con pipeline, contenitore, compilazione e risorse del 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, definire una risorsa webhook nella pipeline e puntare a 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 eseguito un nuovo trigger di 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: uguale al 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: intestazione HTTP nella richiesta contenente 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'esecuzione abbia prodotto tutti gli artefatti necessari. Non è necessario attendere il completamento di un'esecuzione CI o eseguirla di nuovo a causa di un errore di fase non correlato.

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 la selezione della versione della risorsa 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 si è membri del ruolo Utente per la risorsa, è possibile selezionare questa opzione e autorizzare la risorsa nella compilazione 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 ha attivato la pipeline.
  • Versione della risorsa e artefatti utilizzati.
  • Commit associati a 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.

Informazioni sulle pipeline cd associate nelle pipeline CI

Per fornire la tracciabilità end-to-end, è possibile tenere traccia delle pipeline cd che usano una pipeline CI specifica tramite la pipelines risorsa. Se altre pipeline usano la pipeline CI, viene visualizzata una scheda Pipeline associate nella visualizzazione Esegui . La vista mostra tutte le esecuzioni di pipeline YAML CD che hanno utilizzato la pipeline CI e gli artefatti da esso.

Screenshot che mostra le informazioni sulle pipeline cd in una pipeline CI.

Problemi relativi al trigger di 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 del trigger non corrispondono.

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

Screenshot che mostra i problemi di 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 il supporto 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'uso di una pipelines risorsa è un modo per utilizzare gli artefatti da una pipeline di integrazione continua e configurare anche 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 usare il download collegamento per scaricare gli artefatti nei processi di compilazione o per eseguire l'override del 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, potrebbe essere presente un'attività script archiviata in un modello diverso che richiede il download degli artefatti di una compilazione. In alternativa, potrebbe non essere necessario aggiungere una risorsa pipeline a un modello. Per evitare dipendenze, è possibile usare l'attività Scarica artefatti pipeline per passare tutte le informazioni di compilazione a un'attività.

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

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

  1. Creare una nuova connessione al servizio Docker Hub.
  2. Creare una pipeline di versione classica e aggiungere un artefatto dell'hub Docker. 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 attivare o disattivare 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à, l'account di accesso Docker 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 denominare il webhook nella webhooks sezione .

    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 di codice di stato 200, il webhook è pronto per l'utilizzo 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. In Ramo predefinito per le compilazioni manuali e pianificate aggiornare il ramo delle funzionalità.
  5. Selezionare Salva e coda.
  6. Dopo l'esecuzione 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