Partage via

Ressources dans les pipelines YAML

  • Article

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.

Important

Lorsque vous définissez un déclencheur de ressource de pipeline :

  • Si la ressource pipeline provient du même référentiel que le pipeline actuel, ou self, le déclenchement suit la même branche et la même validation sur lesquelles l’événement est déclenché.
  • Si la ressource de pipeline provient d’un autre référentiel, le pipeline actuel se déclenche sur la branche par défaut du référentiel de la ressource pipeline.

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.

Propriétés spécifiées Version de l’artefact
version Les artefacts de la build ayant le numéro d’exécution spécifié
branch Les artefacts de la dernière build effectuée sur la branche spécifiée
Liste tags Artefacts du dernier build qui contient toutes les balises spécifiées
Liste branch et tags Les artefacts de la dernière build effectuée sur la branche spécifiée qui a toutes les balises spécifiées
Aucune Artefacts du dernier build sur toutes les branches

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.

Déclencheurs spécifiés Résultat
branches Une nouvelle exécution de pipeline se déclenche chaque fois que le pipeline de ressource termine avec succès une exécution sur l’une des branches include.
tags Une nouvelle exécution de pipeline se déclenche chaque fois que le pipeline de ressource termine avec succès une exécution étiquetée avec toutes les balises spécifiées.
stages Une nouvelle exécution de pipeline se déclenche chaque fois que le pipeline de ressource exécute avec succès le stages spécifié.
branches, tags et stages Une nouvelle exécution de pipeline se déclenche chaque fois que l’exécution du pipeline de ressource satisfait toutes les conditions de branche, de balises et d’étapes.
trigger: true Une nouvelle exécution de pipeline se déclenche chaque fois que le pipeline de ressource termine avec succès une exécution.
Rien Aucune nouvelle exécution de pipeline ne se déclenche lorsque le pipeline de ressource termine avec succès une exécution.

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'

Variables de ressource de pipeline

À chaque exécution, les métadonnées d’une ressource de pipeline sont disponibles pour toutes les tâches sous forme de variables prédéfinies. Ces variables sont disponibles pour votre pipeline uniquement à l’exécution, et ne peuvent donc pas être utilisées dans les expressions de modèle, qui sont évaluées au moment de la compilation du pipeline.

Pour plus d’informations, consultez Métadonnées de ressources de pipeline en tant que variables prédéfinies. Pour en savoir plus sur la syntaxe des variables, consultez Définir des variables.

L’exemple suivant renvoie les valeurs des variables prédéfinies pour la ressource de pipeline myresourcevars.

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

Important

Les déclencheurs sont pris en charge uniquement pour Jenkins hébergé lorsque Azure DevOps a une ligne de vue avec le serveur Jenkins.

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.

Type Valeur du nom Exemple
type: git Un autre référentiel dans le même projet ou la même organisation. Même projet : name: otherRepo
Un autre projet dans la même organisation : name: otherProject/otherRepo.
type: github Nom complet du référentiel GitHub incluant l’utilisateur ou l’organisation. name: Microsoft/vscode
type: githubenterprise Nom complet du référentiel GitHub Enterprise incluant l’utilisateur ou l’organisation. name: Microsoft/vscode
type: bitbucket Nom complet du référentiel Bitbucket Cloud incluant l’utilisateur ou l’organisation. name: MyBitbucket/vscode

Variables de ressource de référentiel

À chaque exécution, les métadonnées suivantes pour une ressource de référentiel sont disponibles pour toutes les tâches sous forme de variables à l’exécution. Le <Alias> est l’identifiant que vous donnez à votre 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

L’exemple suivant a une ressource de référentiel avec un alias de common, de sorte que les variables de ressource du référentiel sont accessibles en utilisant 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)"

À chaque exécution, les métadonnées suivantes pour une ressource de référentiel sont disponibles pour toutes les tâches sous forme de variables à l’exécution. Le <Alias> est l’identifiant que vous donnez à votre 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.<Alias>.version

L’exemple suivant a une ressource de référentiel avec un alias de common, de sorte que les variables de ressource du référentiel sont accessibles en utilisant 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)"

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.

Remarque

La syntaxe enabled: 'true' pour activer les déclencheurs de conteneur pour toutes les balises d’image est différente de la syntaxe pour d’autres déclencheurs de ressource. Assurez-vous d’utiliser la syntaxe correcte pour des ressources spécifiques.

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*

Remarque

L’évaluation des déclencheurs ne se produit que sur la branche par défaut. Assurez-vous de définir la branche par défaut correcte ou de fusionner le fichier YAML dans la branche par défaut actuelle. Pour plus d’informations sur la façon de changer la branche par défaut du pipeline, consultez La branche par défaut du pipeline.

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)

Définition des ressources de packages

Vous pouvez consommer des packages NuGet et npm GitHub en tant que ressources dans les pipelines YAML. Pour activer les déclencheurs automatiques de pipeline lorsqu’une nouvelle version de package est publiée, définissez la propriété trigger sur true.

Lorsque vous définissez des ressources package, spécifiez le <Référentiel>/<Nom> du package dans la propriété name, et définissez le package type en tant que NuGet ou npm. Pour utiliser les packages GitHub, utilisez l’authentification basée sur un jeton d’accès personnel (PAT) et créez une connexion de service GitHub qui utilise le PAT.

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

Par défaut, les packages ne sont pas téléchargés automatiquement dans les travaux. Pour télécharger, utilisez getPackage.

L’exemple suivant présente une connexion de service GitHub nommée pat-contoso à un package npm GitHub nommé contoso. Pour plus d’informations, consultez Packages 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

Définition des ressources Webhooks

Remarque

Les webhooks ont été publiés dans Azure DevOps Server 2020.1.

Vous pouvez consommer des artefacts et activer des déclencheurs automatisés avec des ressources de pipeline, de conteneur, de build et de package. Cependant, vous ne pouvez pas utiliser ces ressources pour automatiser vos déploiements en fonction d’événements ou de services externes.

La ressource webhooks dans les pipelines YAML vous permet d’intégrer vos pipelines avec des services externes tels que GitHub, GitHub Enterprise, Nexus et Artifactory pour automatiser les workflows. Vous pouvez vous abonner à tout événement externe via des webhooks et utiliser les événements pour déclencher vos pipelines.

Les webhooks automatisent votre workflow en fonction de tout événement webhook externe qui n’est pas pris en charge par les ressources de premier ordre telles que les pipelines, les builds, les conteneurs ou les packages. De plus, pour les services sur site où Azure DevOps n’a pas de visibilité sur le processus, vous pouvez configurer des webhooks sur le service et déclencher automatiquement vos pipelines.

Pour vous abonner à un événement webhook, vous définissez une ressource webhook dans votre pipeline et la pointez vers une connexion de service webhook entrant. Vous pouvez également définir d’autres filtres sur la ressource webhook, en fonction des données de charge utile JSON, pour personnaliser les déclencheurs pour chaque pipeline.

Chaque fois que la connexion de service webhook entrant reçoit un événement webhook, une nouvelle exécution se déclenche pour tous les pipelines abonnés à l’événement webhook. Vous pouvez consommer les données du payload JSON dans vos tâches sous forme de variables en utilisant le format ${{ parameters.<WebhookAlias>.<JSONPath>}}.

Pour des informations complètes sur le schéma, consultez la section définition des webhooks.resources.webhooks.

L’exemple suivant définit une ressource webhook :

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

Déclencheurs Webhook

Pour configurer des déclencheurs webhook, vous devez d’abord configurer un webhook sur votre service externe, en fournissant les informations suivantes :

  • URL de la requête : https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
  • Secret (Optionnel) : Si vous devez sécuriser votre payload JSON, fournissez une valeur secrète.

Ensuite, vous créez une nouvelle connexion de service webhook entrant. Pour ce type de connexion de service, vous définissez les informations suivantes :

  • Nom du WebHook : Identique à celui créé dans votre service externe.
  • Secret (Optionnel) : Utilisé pour vérifier le hachage HMAC-SHA1 du payload pour la vérification de la requête entrante. Si vous avez utilisé un secret lors de la création de votre webhook, vous devez fournir le même secret.
  • En-tête HTTP : L’en-tête HTTP de la requête qui contient la valeur du hachage HMAC-SHA1 du payload pour la vérification de la requête. Par exemple, l’en-tête de requête GitHub est X-Hub-Signature.

Capture d’écran montrant la connexion de service webhook entrant.

Pour déclencher votre pipeline en utilisant un webhook, vous effectuez une requête POST à https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Ce point de terminaison est publiquement disponible et ne nécessite aucune autorisation. La requête doit avoir un corps semblable à l’exemple suivant :

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

Remarque

Accéder aux données du corps de la requête du webhook peut entraîner une erreur YAML incorrecte. Par exemple, l’étape de pipeline - script: echo ${{ parameters.WebHook.resource.message }} extrait le message JSON entier, ce qui génère un YAML invalide. Tout pipeline déclenché via ce webhook ne s’exécute pas, car le YAML généré est devenu invalide.

L’extrait suivant montre un autre exemple qui utilise des filtres de 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}}

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.

Capture d’écran montrant le sélecteur de version des ressources de référentiel.

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.

Capture d’écran montrant les validations dans un environnement.

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.

Capture d’écran montrant les informations des pipelines CD dans un pipeline 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.

Capture d’écran montrant Problèmes de déclenchement sur la page principale du pipeline.

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

Capture d’écran montrant la prise en charge des problèmes de déclenchement.

Forum aux questions

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