Ressources dans des pipelines YAML

Article
07/02/2024

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 qui existe en dehors du pipeline. Après avoir défini une ressource, vous pouvez l’utiliser n’importe où dans votre pipeline.

Les ressources fournissent une traçabilité complète pour les services que votre pipeline utilise, notamment la version, les artefacts, les validations associées et les éléments de travail. Vous pouvez automatiser entièrement vos flux de travail DevOps en vous abonnant pour déclencher des événements 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 obtenir des informations complètes sur le schéma, consultez la définition des ressources dans la référence de 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 de ressource pipelines

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 pipelines ressource. Vous pouvez définir des déclencheurs pour vos flux de travail de déploiement continu (CD) sur une ressource de pipeline.

Dans votre définition de ressource, pipeline il s’agit d’une valeur unique que vous pouvez utiliser pour référencer la ressource de pipeline ultérieurement dans votre pipeline. Il source s’agit du nom du pipeline qui a produit l’artefact de pipeline. Pour obtenir des informations de schéma complètes, consultez la définition resources.pipelines.pipeline.

Vous utilisez l’étiquette définie par pipeline pour référencer la ressource de pipeline à partir d’autres parties de votre pipeline, par exemple lorsque vous utilisez des variables de ressource de pipeline ou téléchargez des artefacts. Pour obtenir une autre façon de télécharger des artefacts de pipeline, consultez Télécharger les artefacts.

Important

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

Si la pipeline ressource provient du même référentiel que le pipeline actuel, ou selfsi le déclenchement suit la même branche et la même validation sur laquelle 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 pipeline référentiel de ressources.

Exemples de définitions de ressources de pipeline

L’exemple suivant utilise des artefacts à partir 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 utiliser un pipeline à partir 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 avoir 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 trigger de pipeline avec des conditions de branche.

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

L’exemple suivant utilise stages des filtres pour évaluer les conditions de déclencheur pour les pipelines CD. Les étapes utilisent l’opérateur AND . Une fois toutes les étapes fournies terminées, le pipeline CD se déclenche.

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

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

Les tags éléments 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 des artefacts de pipelines

La version de l’artefact du pipeline de ressources 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 ou planifiée manuellement, les valeurs du , branchet tags les propriétés définissent la version de versionl’artefact. L’entrée branch ne peut pas avoir de caractères génériques. Les tags propriétés utilisent l’opérateur AND .

Propriétés spécifiées	Version de l’artefact
`version`	Artefacts de la build qui ont le numéro d’exécution spécifié
`branch`	Artefacts de la dernière build effectuée sur la branche spécifiée
`tags` liste	Artefacts du dernier build qui contient toutes les balises spécifiées
Liste `branch` et `tags`	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 suivante pipeline utilise les propriétés et tags les branch propriétés 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 de MyCIAlias pipeline est la dernière build effectuée sur la main branche qui a les balises et PrepProduction les Production balises.

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

Déclencheur d’achèvement du pipeline de ressources

Lorsqu’un pipeline se déclenche parce qu’un de ses pipelines de ressources est terminé, la version des artefacts est la version du pipeline de déclenchement. 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 ressources termine correctement une exécution sur l’une des `include` branches.
`tags`	Une nouvelle exécution de pipeline se déclenche chaque fois que le pipeline de ressources termine correctement une exécution marquée avec toutes les balises spécifiées.
`stages`	Une nouvelle exécution de pipeline se déclenche chaque fois que le pipeline de ressources exécute correctement le pipeline spécifié `stages`.
`branches`, `tags` et `stages`	Une nouvelle exécution de pipeline se déclenche chaque fois que l’exécution du pipeline de ressources 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 ressources termine correctement une exécution.
Rien	Aucun nouveau déclencheur d’exécution de pipeline lorsque le pipeline de ressources termine correctement une exécution.

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

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

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 pipeline ressources sont automatiquement téléchargés et mis à disposition au début de chaque travail de déploiement. Vous pouvez remplacer ce comportement en définissant downloadnonesur , ou en spécifiant un autre identificateur de ressource de pipeline.

Les artefacts de travail standard ne sont pas téléchargés automatiquement. Utilisez download explicitement si nécessaire.

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

La propriété facultative artifact spécifie les noms d’artefacts. Si ce n’est pas spécifié, tous les artefacts disponibles sont téléchargés. La propriété facultative patterns définit des modèles qui représentent des fichiers à inclure. Pour obtenir des informations complètes sur le schéma, consultez la définition steps.download.

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

Variables de ressource de pipeline

Dans chaque exécution, les métadonnées d’une ressource de pipeline sont disponibles pour tous les travaux en tant que variables prédéfinies. Ces variables sont disponibles uniquement pour votre pipeline au moment de 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 retourne les valeurs de variable prédéfinies pour la ressource de myresourcevars pipeline.

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

Génère une définition de ressource

Si vous disposez d’un système de génération CI externe qui produit des artefacts, vous pouvez consommer des artefacts avec builds des ressources. Une build ressource peut provenir de n’importe quel système CI externe tel que Jenkins, TeamCity ou CircleCI.

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

Dans la build définition, version la version réussie est la plus récente par défaut. L’option trigger n’est pas activée par défaut et doit être définie explicitement. Pour obtenir des informations de schéma complètes, consultez la définition resources.builds.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 pour Jenkins hébergé uniquement lorsque Azure DevOps a une ligne de vue avec le serveur Jenkins.

Tâche downloadBuild

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

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

Dans la downloadBuild définition, vous spécifiez la ressource à partir de laquelle télécharger des artefacts. La propriété facultative artifact spécifie les artefacts à télécharger. S’il n’est pas spécifié, tous les artefacts associés à la ressource sont téléchargés.

La propriété facultative patterns définit un chemin d’accès minimatch ou une liste de chemins d’accès minimatch à télécharger. S’il est vide, l’ensemble de l’artefact est téléchargé. Par exemple, l’extrait de code suivant télécharge uniquement les fichiers *.zip .

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

Pour obtenir des informations de schéma complètes, consultez la 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 possède des modèles dans un autre référentiel ou si vous souhaitez utiliser l’extraction multipo 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 obtenir des informations de schéma complètes, consultez la définition resources.repository.repository.

Types de ressources de référentiel

Azure Pipelines prend en charge les valeurs suivantes pour le type de référentiel : git, , github, githubenterpriseet 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.

Type	Valeur de 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 dépôt GitHub, y compris l’utilisateur ou l’organisation.	`name: Microsoft/vscode`
`type: githubenterprise`	Nom complet du dépôt GitHub Enterprise, y compris l’utilisateur ou l’organisation.	`name: Microsoft/vscode`
`type: bitbucket`	Nom complet du dépôt Bitbucket Cloud, y compris l’utilisateur ou l’organisation.	`name: MyBitbucket/vscode`

Variables de ressources du référentiel

Dans chaque exécution, les métadonnées suivantes pour une ressource de référentiel sont disponibles pour tous les travaux sous la forme de variables d’exécution. Il <Alias> s’agit de l’identificateur 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 contient une ressource de référentiel avec un alias de , de sorte que les variables de commonressource de référentiel sont accessibles à l’aide resources.repositories.common.*de .

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é d’extraction pour les référentiels

Les référentiels de la ressource repository ne sont pas synchronisés automatiquement dans vos travaux. Utilisez le checkout mot clé pour extraire un référentiel défini dans le cadre de la repository ressource. Pour obtenir des informations de schéma complètes, consultez la définition steps.checkout.

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

Définition de ressource de conteneurs

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

Vous pouvez utiliser une image de ressource conteneur générique dans le cadre de votre travail ou utiliser la ressource pour les travaux de conteneur. Si votre pipeline nécessite la prise en charge 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 devez consommer des images à partir d’un registre Docker dans le cadre de votre pipeline, vous pouvez définir une ressource de conteneur générique. Aucun mot clé n’est type requis. Par exemple :

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

Pour obtenir des informations de schéma complètes, consultez la définition resources.containers.container.

Remarque

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

Type de ressource Azure Container Registry

Pour utiliser vos images Azure Container Registry, vous pouvez utiliser le type acrde ressource de conteneur de première classe. Vous pouvez utiliser ce type de ressource dans le cadre de vos travaux et activer les déclencheurs de pipeline automatique.

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

Pour utiliser le acr type de ressource, vous devez spécifier les valeurs et repository les azureSubscriptionresourceGroupvaleurs de 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

Les connexions de service qui utilisent la fédération d’identité de charge de travail ne sont pas prises en charge dans azureSubscription.

Variables de ressources de conteneur

Une fois que vous avez défini un conteneur en tant que ressource, les métadonnées d’image conteneur passent au pipeline en tant que variables. Les informations telles que l’image, le Registre et les détails de connexion sont accessibles dans tous les travaux utilisés 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 location variable s’applique uniquement au acr type de ressources de conteneur.

L’exemple suivant contient 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 de ressource de packages

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

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

Pour obtenir des informations complètes sur le schéma, consultez la définition de resources.packages.package.

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 contient 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 de ressource 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. Toutefois, vous ne pouvez pas utiliser ces ressources pour automatiser vos déploiements en fonction d’événements ou de services externes.

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

Les webhooks automatisent votre flux de travail en fonction d’un événement de webhook externe qui n’est pas pris en charge par des ressources de première classe telles que des pipelines, des builds, des conteneurs ou des packages. En outre, pour les services locaux 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 pointez-la vers une connexion de service webhook entrante. 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 du service webhook entrante reçoit un événement webhook, un nouveau déclencheur d’exécution pour tous les pipelines abonnés à l’événement webhook. Vous pouvez utiliser les données de charge utile JSON dans vos travaux en tant que variables à l’aide du format ${{ parameters.<WebhookAlias>.<JSONPath>}}.

Pour obtenir des informations de schéma complètes, consultez la définition resources.webhooks.webhook.

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 de webhook, vous devez d’abord configurer un webhook sur votre service externe, en fournissant les informations suivantes :

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

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

Nom du webHook : identique au webhook créé dans votre service externe.
Secret (facultatif) : utilisé pour vérifier le hachage HMAC-SHA1 de la charge utile 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 : en-tête HTTP dans la requête qui contient la valeur de hachage HMAC-SHA1 de la charge utile pour la vérification de la demande. Par exemple, l’en-tête de requête GitHub est X-Hub-Signature.

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

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

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

Remarque

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

L’extrait de code 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 manuelle 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. Toutefois, Azure Pipelines considère uniquement que les exécutions CI terminées correctement 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 ressource pour choisir manuellement une autre version lorsque vous créez une exécution. Le sélecteur de versions de ressource est pris en charge pour les ressources de pipeline, de build, de dépôt, 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 ou de la branche du pipeline, puis choisir une exécution réussie, ayant échoué 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 ou de la réexécuter en raison d’un échec d’étape non lié.

Pour utiliser le sélecteur de versions de ressource, 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 de ressource du référentiel.

Pour les ressources où vous ne pouvez pas extraire les versions disponibles, telles que les packages GitHub, le sélecteur de versions fournit un champ de texte afin de pouvoir entrer la version de l’exécution à sélectionner.

Autorisation des ressources dans les pipelines YAML

Les ressources doivent être autorisées avant de pouvoir être utilisées dans des pipelines. Les propriétaires de 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 les paramètres project. Cette autorisation est pratique si vous n’avez pas besoin de restreindre l’accès aux ressources, par exemple 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 à ê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 voyez une option permettant d’autoriser les ressources sur la build ayant échoué.

Si vous êtes membre du rôle Utilisateur pour la ressource, vous pouvez sélectionner cette option et autoriser la ressource sur la build ayant échoué. Une fois la ressource autorisée, vous pouvez démarrer 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 des ressources

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

La définition d’une approbation de modèle requise garantit que votre ressource est utilisée uniquement dans des conditions spécifiques et améliore la sécurité. Pour en savoir plus sur l’amélioration de la sécurité des pipelines avec des modèles, consultez Utiliser des modèles pour la sécurité.

Traçabilité

Azure Pipelines offre une traçabilité complète pour toutes les ressources consommées au niveau d’un pipeline ou d’un travail 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.
Version de la ressource et 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 inclut les ressources consommées dans le cadre des travaux de déploiement et de 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 les pipelines CD qui consomment un pipeline CI spécifique via la pipelines ressource. Si d’autres pipelines consomment votre pipeline CI, vous voyez un onglet Pipelines associés dans la vue Exécuter . La vue affiche toutes les exécutions de pipeline YAML CD qui ont consommé votre pipeline CI et les artefacts à partir de celui-ci.

Capture d’écran montrant les informations sur les pipelines CD dans un pipeline CI.

Problèmes de déclencheur de ressources

Les déclencheurs de ressources peuvent échouer à s’exécuter, car :

La source de la connexion de service fournie n’est pas valide, il existe des erreurs de syntaxe dans le déclencheur ou le déclencheur n’est pas configuré.
Les conditions de déclencheur ne sont pas mises en correspondance.

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éclencheur dans la page de définition de pipeline. Les problèmes de déclencheur sont disponibles uniquement pour les ressources autres que les ressources.

Dans la page Problèmes du déclencheur, 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éclencheur.

Forum aux questions

Quand dois-je utiliser des ressources de pipelines, 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 travaux de déploiement.

Vous pouvez utiliser le download raccourci pour télécharger les artefacts dans les travaux de génération ou pour remplacer le comportement de téléchargement dans les travaux de déploiement. Pour plus d’informations, consultez la 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 judicieux d’utiliser cette tâche directement. Par exemple, vous pouvez avoir une tâche de script stockée dans un autre modèle qui nécessite le téléchargement d’artefacts à partir d’une build. Vous ne souhaiterez peut-être pas 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 mise en production classique.

Créez une nouvelle connexion de service Docker Hub.
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 source.
Sélectionnez le déclencheur et basculez le déclencheur de déploiement continu sur Activer. Chaque push Docker qui se produit dans le référentiel sélectionné crée une mise en production.
Créez un nouvel index et un nouveau travail. Ajoutez deux tâches, la connexion Docker 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 ?

Créez une connexion de service.

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

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

Exécuter votre pipeline. Le webhook est créé dans Azure en tant que tâche distribuée pour votre organisation.
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 de code d’état 500 avec l’erreurCannot find webhook for the given webHookId ..., votre code peut se trouver dans une branche qui n’est pas votre branche par défaut. Pour résoudre ce problème :

Sélectionnez Modifier dans votre page de pipeline.
Dans le menu Autres actions , sélectionnez Déclencheurs.
Sélectionnez l’onglet YAML , puis sélectionnez Obtenir des sources.
Sous Branche par défaut pour les builds manuelles et planifiées, mettez à jour votre branche de fonctionnalité.
Sélectionnez Enregistrer et mettre en file d’attente.
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.

Partage via

Ressources dans des pipelines YAML

Schéma des ressources

Définition de ressource pipelines

Exemples de définitions de ressources de pipeline

Évaluation de la version des artefacts de pipelines

Déclencheur manuel ou planifié

Déclencheur d’achèvement du pipeline de ressources

Téléchargement d’artefacts de pipeline

Variables de ressource de pipeline

Génère une définition de ressource

Tâche downloadBuild

Définition de ressources de référentiel

Types de ressources de référentiel

Variables de ressources du référentiel

Mot clé d’extraction pour les référentiels

Définition de ressource de conteneurs

Type de ressource Azure Container Registry

Variables de ressources de conteneur

Définition de ressource de packages

Définition de ressource webhooks

Déclencheurs Webhook

Sélecteur de version manuelle pour les ressources

Autorisation des ressources dans les pipelines YAML

Vérifications d’approbation des ressources

Traçabilité

Traçabilité des pipelines

Traçabilité de l’environnement

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

Problèmes de déclencheur de ressources

Forum aux questions

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

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

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

Commentaires

Commentaires

Ressources supplémentaires

Partage via

Ressources dans des pipelines YAML

Schéma des ressources

Définition de ressource pipelines

Exemples de définitions de ressources de pipeline

Évaluation de la version des artefacts de pipelines

Déclencheur manuel ou planifié

Déclencheur d’achèvement du pipeline de ressources

Téléchargement d’artefacts de pipeline

Variables de ressource de pipeline

Génère une définition de ressource

Tâche downloadBuild

Définition de ressources de référentiel

Types de ressources de référentiel

Variables de ressources du référentiel

Mot clé d’extraction pour les référentiels

Définition de ressource de conteneurs

Type de ressource Azure Container Registry

Variables de ressources de conteneur

Définition de ressource de packages

Définition de ressource webhooks

Déclencheurs Webhook

Sélecteur de version manuelle pour les ressources

Autorisation des ressources dans les pipelines YAML

Vérifications d’approbation des ressources

Traçabilité

Traçabilité des pipelines

Traçabilité de l’environnement

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

Problèmes de déclencheur de ressources

Forum aux questions

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

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

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

Contenu connexe

Commentaires

Commentaires

Ressources supplémentaires