Ressources dans les pipelines YAML

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

Cet article traite des ressources pour les pipelines YAML. Une ressource est tout ce qui est utilisé par un pipeline et qui existe en dehors du pipeline. Après avoir défini une ressource, vous pouvez l’utiliser partout dans votre pipeline.

Les ressources offrent une traçabilité complète des services utilisés par votre pipeline, y compris la version, les artefacts, les validations associées et les éléments de travail. Vous pouvez automatiser complètement vos workflows DevOps en vous abonnant aux événements déclencheurs sur vos ressources.

Schéma des ressources

Les ressources dans YAML représentent des sources de pipelines, de builds, de référentiels, de conteneurs, de packages et de webhooks. Pour des informations complètes sur le schéma, veuillez consulter la section définition des ressources dans la référence du schéma YAML pour Azure Pipelines.

Lorsqu’une ressource déclenche un pipeline, les variables suivantes sont définies :

resources.triggeringAlias
resources.triggeringCategory

La variable Build.Reason doit être ResourceTrigger pour que ces valeurs soient définies. Les valeurs sont vides si une ressource n’a pas déclenché l’exécution du pipeline.

Définition des ressources de pipeline

Si vous avez un pipeline qui produit des artefacts, vous pouvez utiliser les artefacts en définissant une ressource pipelines. Seuls Azure Pipelines peuvent utiliser la ressource pipelines. Vous pouvez définir des déclencheurs pour vos workflows de déploiement continu (CD) sur une ressource de pipeline.

Dans la définition de votre ressource, pipeline est une valeur unique que vous pouvez utiliser pour référencer la ressource du pipeline plus tard dans votre pipeline. Le source est le nom du pipeline qui a produit l’artefact du pipeline. Pour des informations complètes sur le schéma, veuillez consulter la section définition du pipeline.resources.pipelines.

Vous utilisez le label défini par pipeline pour référencer la ressource du pipeline depuis d’autres parties de votre pipeline, comme lors de l’utilisation de variables de ressources de pipeline ou du téléchargement d’artefacts. Pour un autre moyen de télécharger des artefacts de pipeline, veuillez consulter la section Télécharger des artefacts.

Exemples de définitions de ressources de pipeline

L’exemple suivant consomme des artefacts d’un pipeline au sein du même projet.

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

Pour consommer un pipeline d’un autre projet, vous incluez le nom du projet et le nom de la source. L’exemple suivant utilise branch pour résoudre la version par défaut lorsque le pipeline est déclenché manuellement ou planifié. L’entrée de branche ne peut pas contenir de caractères génériques.

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

L’exemple suivant montre une ressource de pipeline avec un déclencheur simple.

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

L’exemple suivant montre une ressource de pipeline trigger avec des conditions de branche.

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

L’exemple suivant utilise des filtres stages pour évaluer les conditions de déclenchement pour les pipelines CD. Les étapes utilisent l’opérateur AND. À l’issue de la réussite de toutes les étapes fournies, le pipeline CD se déclenche.

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

L’exemple suivant utilise des filtres tags pour l’évaluation de la version par défaut et pour les déclencheurs. Les balises utilisent l’opérateur AND.

Les tags sont définis sur le pipeline d’intégration continue (CI) ou CD. Ces balises diffèrent des balises définies sur les branches dans le référentiel Git.

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

Évaluation de la version de l’artefact du pipeline

La version de l’artefact du pipeline de la ressource dépend de la façon dont le pipeline se déclenche.

Déclencheur manuel ou planifié

Si l’exécution du pipeline est déclenchée manuellement ou planifiée, les valeurs des propriétés version, branch et tags définissent la version de l’artefact. L’entrée branch ne peut pas contenir de caractères génériques. Les propriétés tags utilisent l’opérateur AND.

La définition de ressource pipeline suivante utilise les propriétés branch et tags pour évaluer la version par défaut lorsque le pipeline est déclenché manuellement ou planifié. Lorsque vous déclenchez manuellement l’exécution du pipeline, la version des artefacts du pipeline MyCIAlias est la dernière build effectuée sur la branche main qui possède les balises Production et PrepProduction.

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

Déclencheur de fin de pipeline de ressource

Lorsqu’un pipeline se déclenche parce qu’un de ses pipelines de ressource est terminé, la version des artefacts est celle du pipeline déclencheur. Les valeurs des propriétés version, branchet tags sont ignorées.

Le pipeline suivant s’exécute chaque fois que la ressource de pipeline SmartHotel-CI :

• S’exécute sur l’une des branches releases ou sur la branche main
• Est étiquetée avec à la fois Verified et Signed
• Termine à la fois les étapes Production et PreProduction

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

Téléchargement d’artefacts de pipeline

L’étape download télécharge les artefacts associés à l’exécution actuelle ou à une autre ressource de pipeline.

Tous les artefacts du pipeline actuel et toutes ses ressources pipeline sont automatiquement téléchargés et rendus disponibles au début de chaque tâche de déploiement. Vous pouvez remplacer ce comportement en définissant download sur none, ou en spécifiant un autre identifiant de ressource de pipeline.

Les artefacts des tâches régulières ne sont pas automatiquement téléchargés. Utilisez download explicitement si nécessaire.

Les artefacts de la ressource pipeline sont téléchargés dans le dossier $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>. Pour plus d’informations, veuillez consulter la section Publier et télécharger des artefacts de pipeline.

La propriété optionnelle artifact spécifie les noms des artefacts. Si non spécifié, tous les artefacts disponibles sont téléchargés. La propriété optionnelle patterns définit des motifs qui représentent les fichiers à inclure. Pour des informations complètes sur le schéma, veuillez consulter la section définition 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)

Définition des ressources de build

Si vous avez un système de build CI externe qui produit des artefacts, vous pouvez consommer ces artefacts avec des ressources builds. Une ressource build peut provenir de n’importe quel système CI externe comme Jenkins, TeamCity ou CircleCI.

La catégorie builds est extensible. Vous pouvez écrire une extension pour consommer des artefacts de votre service de build et introduire un nouveau type de service dans le cadre de builds.

Dans la définition de build, version est par défaut la dernière build réussie. La ressource trigger n’est pas activée par défaut et doit être explicitement définie. Pour des informations complètes sur le schéma, veuillez consulter la section définition du build.resources.build.

Dans l’exemple suivant, Jenkins est la ressource type.

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

La tâche downloadBuild

Les artefacts de la ressource build ne sont pas automatiquement téléchargés dans vos tâches/tâches de déploiement. Pour consommer des artefacts de la ressource build dans le cadre de vos tâches, vous devez ajouter explicitement la tâche downloadBuild. Vous pouvez personnaliser le comportement de téléchargement pour chaque déploiement ou travail.

Cette tâche se résout automatiquement en la tâche de téléchargement correspondante pour le type de ressource build défini par le runtime. Les artefacts de la ressource build sont téléchargés dans le dossier $(PIPELINE.WORKSPACE)/<build-identifier>/.

Dans la définition de downloadBuild, vous spécifiez la ressource à partir de laquelle télécharger des artefacts. La propriété optionnelle artifact spécifie les artefacts à télécharger. Si non spécifié, tous les artefacts associés à la ressource sont téléchargés.

La propriété optionnelle patterns définit un chemin minimatch ou une liste de chemins minimatch à télécharger. Si vide, l’artefact entier est téléchargé. Par exemple, l’extrait suivant télécharge uniquement les fichiers *.zip.

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

Pour des informations complètes sur le schéma, veuillez consulter la section définition steps.downloadBuild.

Définition de ressources de référentiel

Le mot clé repository vous permet de spécifier un dépôt externe. Vous pouvez utiliser cette ressource si votre pipeline a des modèles dans un autre référentiel ou si vous souhaitez utiliser multi-repo checkout avec un référentiel qui nécessite une connexion de service. Vous devez informer le système de ces référentiels.

Par exemple :

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

Pour des informations complètes sur le schéma, veuillez consulter la section définition du référentiel.resources.repositories.

Types de ressources de référentiel

Azure Pipelines prend en charge les valeurs suivantes pour le type de référentiel : git, github, githubenterprise, et bitbucket.

• Le type git fait référence aux référentiels Git Azure Repos.
• Les référentiels GitHub Enterprise nécessitent une connexion de service GitHub Enterprise pour l’autorisation.
• Les référentiels Bitbucket Cloud nécessitent une connexion au service Bitbucket Cloud pour l’autorisation.

Variables de ressource de référentiel

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

Mot-clé checkout pour les référentiels

Les référentiels de la ressource repository ne sont pas synchronisés automatiquement dans vos travaux. Utilisez le mot-clé checkout pour récupérer un référentiel défini comme partie de la ressource repository. Pour des informations complètes sur le schéma, veuillez consulter la section définition steps.checkout.

Pour plus d’informations, consultez Utiliser plusieurs référentiels dans votre pipeline.

Définition des ressources de conteneurs

Si vous avez besoin de consommer des images de conteneurs dans le cadre de vos pipelines CI/CD, vous pouvez utiliser des ressources containers. Une ressource container peut être un registre Docker public ou privé ou une instance d’Azure Container Registry.

Vous pouvez consommer une image de ressource de conteneur générique dans le cadre de votre tâche, ou utiliser la ressource pour des tâches de conteneur. Si votre pipeline nécessite le support d’un ou plusieurs services, vous devez créer et vous connecter à des conteneurs de service. Vous pouvez utiliser des volumes pour partager des données entre des services.

Si vous avez besoin de consommer des images depuis un registre Docker dans le cadre de votre pipeline, vous pouvez définir une ressource de conteneur générique. Aucun mot-clé type n’est requis. Par exemple :

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

Pour des informations complètes sur le schéma, veuillez consulter la section définition du conteneur.resources.containers.

Type de ressource Azure Container Registry

Pour consommer vos images Azure Container Registry, vous pouvez utiliser le type de ressource de conteneur de première classe acr. Vous pouvez utiliser ce type de ressource dans le cadre de vos tâches et pour activer les déclencheurs de pipeline automatiques.

Vous avez besoin des autorisations Contributeur ou Propriétaire pour Azure Container Registry afin d’utiliser les déclencheurs de pipeline automatiques. Pour plus d’informations, consultez Rôles et autorisations Azure Container Registry.

Pour utiliser le type de ressource acr, vous devez spécifier les valeurs azureSubscription, resourceGroup, et repository pour votre registre de conteneurs Azure. Par exemple :

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

Variables de ressources de conteneur

Une fois que vous avez défini un conteneur comme ressource, les métadonnées de l’image du conteneur sont transmises au pipeline sous forme de variables. Des informations telles que l’image, le registre et les détails de connexion sont accessibles dans toutes les tâches utilisées dans vos tâches de déploiement de conteneur.

Les variables de ressources de conteneur fonctionnent avec Docker et Azure Container Registry. Vous ne pouvez pas utiliser de variables de ressources de conteneur pour les conteneurs d’images locaux. La variable location ne s’applique qu’au type de ressources de conteneur acr.

L’exemple suivant a une connexion de service Azure Resource Manager nommée arm-connection. Pour plus d’informations, consultez Registres de conteneur Azure, référentiels et images.

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

Sélecteur de version manuel pour les ressources

Lorsque vous déclenchez manuellement un pipeline YAML CD, Azure Pipelines évalue automatiquement les versions par défaut des ressources définies dans le pipeline, en fonction des entrées fournies. Cependant, Azure Pipelines ne prend en compte que les exécutions CI complétées avec succès lors de l’évaluation de la version par défaut pour les déclencheurs planifiés, ou si vous ne choisissez pas manuellement une version.

Vous pouvez utiliser le sélecteur de version de la ressource pour choisir manuellement une version différente lors de la création d’une exécution. Le sélecteur de version des ressources est pris en charge pour les ressources de pipeline, de build, de référentiel, de conteneur et de package.

Pour les ressources de pipeline, vous pouvez voir toutes les exécutions disponibles sur toutes les branches, les rechercher en fonction du numéro de pipeline ou de la branche, et choisir une exécution réussie, échouée ou en cours. Cette flexibilité garantit que vous pouvez exécuter votre pipeline CD si vous êtes sûr qu’une exécution a produit tous les artefacts dont vous avez besoin. Vous n’avez pas besoin d’attendre la fin d’une exécution CI, ni de la relancer en raison d’une défaillance d’une étape non liée.

Pour utiliser le sélecteur de version des ressources, dans le volet Exécuter le pipeline, sélectionnez Ressources, puis sélectionnez une ressource et choisissez une version spécifique dans la liste des versions disponibles.

Pour les ressources où vous ne pouvez pas récupérer les versions disponibles, comme les packages GitHub, le sélecteur de version fournit un champ de texte pour que vous puissiez entrer la version à choisir pour l’exécution.

Autorisation des ressources dans les pipelines YAML

Les ressources doivent être autorisées avant de pouvoir être utilisées dans les pipelines. Les propriétaires des ressources contrôlent les utilisateurs et les pipelines qui peuvent accéder à leurs ressources. Il existe plusieurs façons d’autoriser un pipeline YAML à utiliser des ressources.

• Utilisez l’expérience d’administration des ressources pour autoriser tous les pipelines à accéder à la ressource. Par exemple, les groupes de variables et les fichiers sécurisés sont gérés dans la page Bibliothèque sous Pipelines, et les pools d’agents et les connexions de service sont gérés dans Paramètres du projet. Cette autorisation est pratique si vous n’avez pas besoin de restreindre l’accès aux ressources, comme pour les ressources de test.

• Lorsque vous créez un pipeline, toutes les ressources référencées dans le fichier YAML sont automatiquement autorisées pour être utilisées par le pipeline si vous avez le rôle Utilisateur pour ces ressources.

• Si vous ajoutez une ressource à un fichier YAML et que la build échoue avec une erreur telle que Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use., vous verrez une option pour autoriser les ressources sur la build échouée.

  Si vous êtes membre du rôle Utilisateur pour la ressource, vous pouvez sélectionner cette option et autoriser la ressource sur la build échouée. Une fois la ressource autorisée, vous pouvez lancer une nouvelle build.

• Vérifiez que les rôles de sécurité du pool d’agents de votre projet sont corrects.

Vérifications d’approbation pour les ressources

Vous pouvez utiliser des vérifications d’approbation et des modèles pour contrôler manuellement quand une ressource s’exécute. Avec la vérification d’approbation de modèle requise, vous pouvez exiger que tout pipeline utilisant une ressource ou un environnement s’étende à partir d’un modèle YAML spécifique.

Définir une approbation de modèle requise garantit que votre ressource n’est utilisée que dans des conditions spécifiques et améliore la sécurité. Pour en savoir plus sur la façon d’améliorer la sécurité du pipeline avec des modèles, consultez la section Utiliser des modèles pour la sécurité.

Traçabilité

Azure Pipelines fournit une traçabilité complète pour toute ressource consommée au niveau d’un pipeline ou d’une tâche de déploiement.

Traçabilité des pipelines

Azure Pipelines affiche les informations suivantes pour chaque exécution de pipeline :

• Si une ressource a déclenché le pipeline, la ressource qui a déclenché le pipeline.
• La version de la ressource et les artefacts consommés.
• Validations associées à chaque ressource.
• Éléments de travail associés à chaque ressource.

Traçabilité de l’environnement

Chaque fois qu’un pipeline est déployé dans un environnement, vous pouvez voir une liste des ressources consommées. La vue comprend les ressources consommées dans le cadre des tâches de déploiement et leurs validations et éléments de travail associés.

Informations sur les pipelines CD associés dans les pipelines CI

Pour fournir une traçabilité de bout en bout, vous pouvez suivre quels pipelines CD consomment un pipeline CI spécifique via la ressource pipelines. Si d’autres pipelines consomment votre pipeline CI, vous verrez un onglet Pipelines associés dans la vue Exécution. La vue montre toutes les exécutions de pipeline YAML CD qui ont consommé votre pipeline CI et les artefacts provenant de celui-ci.

Problèmes de déclenchement de ressources

Les déclencheurs de ressources peuvent ne pas s’exécuter en raison des raisons suivantes :

• La source de la connexion de service fournie est invalide, il y a des erreurs de syntaxe dans le déclencheur ou le déclencheur n’est pas configuré.
• Les conditions de déclenchement ne sont pas remplies.

Pour voir pourquoi les déclencheurs de pipeline n’ont pas pu s’exécuter, sélectionnez l’élément de menu Problèmes de déclenchement sur la page de définition du pipeline. Problèmes de déclenchement est disponible uniquement pour les ressources non liées à un référentiel.

Sur la page Problèmes de déclenchement, les messages d’erreur et d’avertissement décrivent pourquoi le déclencheur a échoué.

Questions fréquentes (FAQ)

Quand dois-je utiliser les ressources de pipeline, le raccourci de téléchargement ou la tâche Télécharger les artefacts de pipeline ?

L’utilisation d’une ressource pipelines permet de consommer des artefacts à partir d’un pipeline CI et de configurer des déclencheurs automatisés. Une ressource vous donne une visibilité complète du processus en affichant la version consommée, les artefacts, les validations et les éléments de travail. Lorsque vous définissez une ressource de pipeline, les artefacts associés sont automatiquement téléchargés dans les tâches de déploiement.

Vous pouvez utiliser le raccourci download pour télécharger les artefacts dans les tâches de build ou pour remplacer le comportement de téléchargement dans les tâches de déploiement. Pour plus d’informations, consultez la section définition steps.download.

La tâche Télécharger les artefacts de pipeline ne fournit pas de traçabilité ni de déclencheurs, mais il est parfois logique d’utiliser cette tâche directement. Par exemple, vous pourriez avoir une tâche de script stockée dans un modèle différent qui nécessite que des artefacts d’une build soient téléchargés. Ou, vous pourriez ne pas vouloir ajouter une ressource de pipeline à un modèle. Pour éviter les dépendances, vous pouvez utiliser la tâche Télécharger les artefacts de pipeline pour transmettre toutes les informations de build à une tâche.

Comment déclencher l’exécution d’un pipeline lorsque mon image Docker Hub est mise à jour ?

Le déclencheur de ressource de conteneur n’est pas disponible pour Docker Hub pour les pipelines YAML, vous devez donc configurer un pipeline de publication classique.

1. Créez une nouvelle connexion de service Docker Hub.
2. Créez un pipeline de mise en production classique et ajoutez un artefact Docker Hub. Définissez votre connexion de service et sélectionnez l’espace de noms, le référentiel, la version et l’alias de la source.
3. Sélectionnez le déclencheur et basculez le déclencheur de déploiement continu sur Activer. Chaque push Docker qui se produit sur le référentiel sélectionné crée une publication.
4. Créez un nouvel index et un nouveau travail. Ajoutez deux tâches, Docker login et Bash.
   • La tâche Docker a l’action login et vous connecte à Docker Hub.
   • La tâche Bash exécute docker pull <hub-user>/<repo-name>[:<tag>].

Comment puis-je valider et dépanner mon webhook ?

1. Créez une connexion de service.

2. Référencez votre connexion de service et nommez votre webhook dans la section webhooks.

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. Exécuter votre pipeline. Le webhook est créé dans Azure en tant que tâche distribuée pour votre organisation.

4. Effectuez un appel d’API POST avec JSON valide dans le corps de https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Si vous recevez une réponse de code d’état de 200, votre webhook est prêt à être utilisé par votre pipeline.

Si vous recevez une réponse avec un code d’état 500 et l’erreur Cannot find webhook for the given webHookId ..., votre code pourrait être dans une branche qui n’est pas votre branche par défaut. Pour résoudre ce problème :

1. Sélectionnez Modifier sur votre page de pipeline.
2. Dans le menu Plus d’actions, sélectionnez Déclencheurs.
3. Sélectionnez l’onglet YAML, puis sélectionnez Obtenir les sources.
4. Sous Branche par défaut pour les builds manuels et planifiés, mettez à jour votre branche de fonctionnalité.
5. Sélectionnez Enregistrer et mettre en file d’attente.
6. Une fois ce pipeline exécuté avec succès, effectuez un appel d’API POST avec JSON valide dans le corps de https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Vous devez maintenant recevoir une réponse de code d’état de 200.

Contenu connexe

• À propos des ressources pour Azure Pipelines.
• Définir des variables
• Ajouter et utiliser des groupes de variables
• Créer et cibler un environnement
• Utiliser l’éditeur de pipeline YAML
• Référence du schéma YAML