Risorse nelle pipeline YAML

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.

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 .

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.

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'

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

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, 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.

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

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* 

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)

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

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

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

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.

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.

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.

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.

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

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

• 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