Risorse nelle pipeline YAML

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Questo articolo illustra le risorse per le pipeline YAML. Una risorsa è qualsiasi elemento usato da una pipeline che esiste all'esterno di tale pipeline. Le risorse nelle pipeline YAML possono essere altre pipeline, compilazioni, contenitori, pacchetti, repository o webhook.

Dopo aver definito una risorsa, è possibile usarla in qualsiasi punto della pipeline. Per altre informazioni ed esempi, vedere Definizioni delle risorse.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

È possibile usare lo stato della risorsa per attivare automaticamente le pipeline impostando la trigger proprietà nella definizione della risorsa. La pipeline resources.triggeringAlias e resources.triggeringCategory le variabili vengono quindi impostate sul nome e la categoria della risorsa. Queste variabili sono vuote a meno che la Build.Reason variabile non sia impostata su ResourceTrigger.

Le risorse consentono la tracciabilità completa per i servizi usati da una pipeline, tra cui versione, artefatti, commit associati ed elementi di lavoro. Se si sottoscrive l'attivazione di eventi sulle risorse, è possibile automatizzare completamente i flussi di lavoro DevOps.

Autorizzazione delle risorse

Le risorse devono essere autorizzate per essere usate 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 le impostazioni di amministrazione della risorsa per concedere le autorizzazioni di accesso a tutte le pipeline. Ad esempio, è possibile gestire file sicuri e gruppi di variabili nella paginaLibreria>, pool di agenti e connessioni al servizio in Pipeline di impostazioni>progetto. Questa autorizzazione è utile per le risorse che non è necessario limitare, ad esempio le risorse di test.

• Assicurarsi di avere almeno il ruolo Utente nei ruoli di sicurezza del pool di agenti per il progetto. Le pipeline YAML create vengono autorizzate automaticamente a usare le risorse in cui si ha il ruolo Utente .

• Se si aggiunge una definizione di risorsa a una pipeline YAML ma 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 usea , assicurarsi di avere almeno il ruolo Utente nella risorsa. È quindi possibile scegliere l'opzione per autorizzare le risorse nella compilazione non riuscita. Dopo aver autorizzato la risorsa, è possibile avviare una nuova compilazione.

Controlli di approvazione per le risorse

È possibile usare i controlli di approvazione e i modelli per controllare manualmente l'uso delle risorse. Usando il controllo di approvazione del modello richiesto, è possibile richiedere qualsiasi pipeline che usi una determinata risorsa o un determinato ambiente per estendersi da un modello YAML specifico.

L'impostazione di un'approvazione del modello necessaria migliora la sicurezza assicurando che la risorsa venga usata solo in condizioni specifiche. Per altre informazioni, vedere Usare i modelli per la sicurezza.

Selezione della versione della risorsa manuale

Azure Pipelines valuta le versioni predefinite per le risorse in base alle definizioni delle risorse. Per le esecuzioni pianificate o le esecuzioni manuali se non si sceglie manualmente un'esecuzione, Azure Pipelines considera solo le esecuzioni di integrazione continua completate correttamente per valutare le versioni predefinite delle risorse.

È possibile usare la selezione della versione della risorsa manuale per scegliere versioni diverse delle risorse quando si attiva manualmente una pipeline di distribuzione continua YAML (CD). La selezione della versione delle risorse è supportata per le risorse della pipeline, della compilazione, del repository, del contenitore e del pacchetto.

Per pipeline le risorse, la selezione della versione manuale consente di visualizzare tutte le esecuzioni disponibili in tutti i rami, cercare le esecuzioni in base al numero o al ramo della pipeline e selezionare un'esecuzione riuscita, non riuscita o in corso.

Non è necessario attendere il completamento di un'esecuzione CI o eseguirla di nuovo a causa di un errore non correlato, prima di poter eseguire la pipeline cd. Si ha la flessibilità di scegliere qualsiasi esecuzione che si conosca di produrre gli artefatti necessari.

Per usare la selezione della versione delle risorse, selezionare Risorse nel riquadro Esegui pipeline , selezionare una risorsa e selezionare una versione specifica dall'elenco delle versioni disponibili. Per le risorse in cui non è possibile recuperare le versioni disponibili, ad esempio i pacchetti GitHub, è possibile immettere la versione desiderata nel campo di testo.

Definizioni delle risorse

Le risorse della pipeline YAML possono essere:

• Altre pipeline
• Costruisce
• Contenitori
• Pacchetti
• Repository o
• Webhook.

Le sezioni seguenti forniscono definizioni ed esempi delle categorie di risorse della pipeline YAML. Per informazioni complete sullo schema, vedere la definizione delle risorse nella guida di riferimento allo schema YAML per Azure Pipelines.

Risorsa Pipelines

È possibile usare le risorse CI pipeline come trigger per i flussi di lavoro cd. È anche possibile fare riferimento pipeline alle risorse dalla pipeline per scaricare gli artefatti o usare le variabili delle risorse della pipeline. Solo Azure Pipelines può usare la pipelines risorsa.

Nella definizione della pipelines risorsa:

• pipeline è un nome univoco usato per fare riferimento alle risorse della pipeline.
• source è il nome della pipeline che ha prodotto gli artefatti della pipeline.

Per informazioni complete sullo schema, vedere la definizione resources.pipelines.pipeline .

Definizioni di risorse della pipeline di esempio

La definizione di risorsa di esempio seguente usa gli artefatti di una pipeline all'interno dello stesso progetto Azure DevOps.

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

Per specificare una pipeline da un altro progetto, includere il project nome nella definizione della risorsa. L'esempio seguente usa branch anche per risolvere la versione predefinita quando la pipeline viene attivata manualmente o in base alla pianificazione. L'input del ramo non può contenere caratteri jolly.

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

Valutazione della versione delle risorse

Azure Pipelines valuta le versioni predefinite per le risorse in base alle definizioni delle risorse. Le versioni predefinite dell'artefatto della risorsa di una pipeline dipendono dal fatto che la pipeline venga eseguita manualmente o in base alla pianificazione o ai trigger in base al risultato dell'esecuzione della risorsa.

Per un'esecuzione manuale o pianificata della pipeline, i valori delle versionproprietà , branche tags nella definizione della pipeline risorsa definiscono le versioni degli artefatti. L'input branch non può avere caratteri jolly e le tags proprietà usano l'operatore AND .

Per le esecuzioni pianificate o le esecuzioni manuali se non si usa lo strumento di selezione della versione, Azure Pipelines considera l'esecuzione dell'integrazione continua completata correttamente durante la valutazione delle versioni predefinite delle risorse. Per le esecuzioni manuali, è possibile eseguire l'override delle versioni definite usando la selezione della versione manuale.

Nella tabella seguente sono elencate pipeline le proprietà di definizione delle risorse e le versioni degli artefatti specificate.

La definizione di risorsa seguente pipeline usa le branch proprietà e tags per valutare la versione predefinita quando la pipeline è pianificata o attivata manualmente. La myCIAlias versione degli artefatti è la build più recente eseguita nel main ramo con i Production tag e PreProduction .

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

Trigger di risorse della pipeline

Per le esecuzioni della pipeline che attivano il risultato di un'esecuzione di una risorsa, le impostazioni delle trigger proprietà nella definizione della risorsa determinano le versioni predefinite dell'artefatto della risorsa. Per usare una pipeline risorsa come trigger per eseguire la pipeline corrente, è necessario impostare la trigger proprietà . Se non si include una trigger proprietà, le esecuzioni delle risorse non attivano le esecuzioni correnti della pipeline.

Quando una pipeline viene attivata in base a un trigger valore in una pipeline definizione di risorsa, i valori della definizione versioncomplessiva della risorsa , branche tags vengono ignorati. Le trigger proprietà determinano le versioni degli artefatti.

Nella tabella seguente viene descritto come le proprietà influiscono sul comportamento del trigger trigger.

Nell'esempio seguente viene illustrata una definizione di risorsa pipeline con un semplice triggeroggetto .

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

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

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

Nell'esempio seguente vengono stages usati filtri per valutare le condizioni di trigger per le pipeline CD. Il trigger stages usa l'operatore AND . La pipeline cd viene attivata al completamento corretto di tutte le fasi elencate.

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

Nell'esempio seguente vengono tags usati filtri per la valutazione della versione predefinita e per il trigger. I trigger tag usano l'operatore AND . Il tags set nelle pipeline definizioni delle risorse è diverso dai tag impostati nei rami nel repository Git.

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

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 .
• Viene contrassegnato con e VerifiedSigned.
• Completa entrambe le Production fasi e PreProduction .

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Scaricamento dell'artefatto dalla pipeline

È possibile usare il download passaggio in una pipeline YAML per scaricare gli artefatti associati all'esecuzione corrente o a un'altra pipeline risorsa.

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

In un normale processo di compilazione, gli artefatti non vengono scaricati automaticamente. Usare download in modo esplicito quando necessario.

download Nel passaggio la proprietà facoltativa artifact specifica i nomi degli artefatti. Se non specificato, tutti gli artefatti disponibili vengono scaricati.

La proprietà facoltativa patterns definisce i modelli che rappresentano i file da scaricare. Per informazioni complete sullo schema, vedere la definizione steps.download .

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

Artefatti dal download della pipeline risorsa in $(PIPELINE. WORKSPACE)/<pipeline-identifier>/<artifact-identifier> cartella. Per altre informazioni, vedere Pubblica e scarica artefatti della pipeline. Per un'alternativa per scaricare gli artefatti della pipeline, vedere Download artifacts.

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)

Crea una risorsa

Se si dispone di un sistema di compilazione CI che produce artefatti, è possibile utilizzare gli artefatti con builds le risorse.

La builds categoria è estendibile. Una build risorsa può essere da qualsiasi sistema CI esterno, ad esempio Jenkins, TeamCity o CircleCI. È possibile usare builds per scrivere un'estensione per utilizzare gli artefatti dal servizio di compilazione o introdurre un nuovo tipo di servizio.

Nella definizione build, il version valore predefinito è la build riuscita più recente. Se necessario, è necessario impostare trigger in modo esplicito. Per informazioni complete sullo schema, vedere la definizione resources.build.build .

Nell'esempio seguente Jenkins è il tipo di risorsa.

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

Attività di downloadBuild

Gli artefatti della risorsa non vengono scaricati automaticamente in build resource artifacts don't automatically download to 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.

L'attività downloadBuild viene risolta automaticamente nell'attività di download corrispondente per il tipo di build risorsa definita dal runtime. Artefatti dal download della build risorsa 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, tutti gli artefatti associati al download della risorsa.

La proprietà facoltativa patterns definisce un percorso o un elenco di percorsi minimatch da scaricare. Se vuoto, l'intero artefatto viene scaricato. Nell'esempio seguente vengono scaricati solo i file *.zip .

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

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

Risorsa repository

Usare la repository parola chiave per informare il sistema sui repository esterni se:

• La pipeline include modelli in un altro repository.
• Si vuole usare il checkout multi-repository con un repository che richiede una connessione al servizio.

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 gittipi di repository , 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.

La tabella seguente descrive i repository tipi di risorsa:

Variabili delle risorse del repository

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

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)"

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

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à. È possibile usare la checkout parola chiave per recuperare un repository definito in una repository risorsa. Per altre informazioni, vedere Consultare più repository nella pipeline. Per informazioni complete sullo schema, vedere la definizione steps.checkout .

Risorsa contenitori

È possibile usare le risorse per usare containers le immagini del contenitore nelle pipeline CI/CD. 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 dei processi o usarla nei processi del contenitore. Se la pipeline richiede il supporto di uno o più servizi, è anche 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, è possibile definire una risorsa contenitore generica senza usare una type parola chiave. Ad esempio:

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

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

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 nei processi e abilitare i trigger automatici della pipeline.

Per usare i trigger automatici della pipeline, sono necessarie le autorizzazioni collaboratore o proprietario del Registro Azure Container. 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* 

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 risorsa 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)

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

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

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

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

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

Tracciabilità

Azure Pipelines offre la tracciabilità completa per qualsiasi risorsa utilizzata a livello di processo di pipeline o distribuzione. Azure Pipelines mostra le informazioni seguenti per ogni esecuzione della pipeline che usa le risorse:

• Se una risorsa ha attivato la pipeline, è la risorsa che l'ha fatto.
• Le versioni delle risorse e gli artefatti utilizzati.
• Commit associati con ogni risorsa.
• Elementi di lavoro associati a ogni risorsa.

Informazioni sulla pipeline cd associata per le pipeline CI

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

Tracciabilità dell'ambiente

Dopo la distribuzione di una pipeline in un ambiente, è possibile visualizzare un elenco di risorse utilizzate e i commit e gli elementi di lavoro associati.

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 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 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 esegue l'azione login e ti accede a Docker Hub.
   • 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.

Perché il trigger della risorsa non funziona?

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

• L'origine della connessione al servizio fornita non è valida.
• Il trigger non è configurato o si verificano errori di sintassi nel trigger.
• 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. I problemi di trigger non sono disponibili per le risorse del repository.

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

Contenuto correlato

• Informazioni sulle risorse per Azure Pipelines
• Definire le variabili
• Aggiungere e usare gruppi di variabili
• Creare un ambiente e sceglierlo come destinazione
• Usare l'editor di pipeline YAML
• Riferimento allo schema YAML