Ressources dans des 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 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, ouself
si 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 , branch
et tags
les propriétés définissent la version de version
l’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
, branch
et 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 lamain
branche - Est marqué avec les deux
Verified
etSigned
- Termine à la fois les phases et
PreProduction
lesProduction
é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 download
none
sur , 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
, 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.
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 common
ressource 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)"
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
resources.repositories.<Alias>.version
L’exemple suivant contient une ressource de référentiel avec un alias de , de sorte que les variables de common
ressource 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 ]
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 acr
de 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 azureSubscription
resourceGroup
valeurs 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é true
sur .
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
.
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.
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.
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.
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é.
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>]
.
- La tâche Docker a l’action
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 dehttps://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 dehttps://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
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez :Soumettre et afficher des commentaires pour