Ressources dans les pipelines YAML

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

Cet article traite des ressources pour les pipelines YAML. Une ressource est tout ce qu’un pipeline utilise qui existe en dehors de ce pipeline. Les ressources des pipelines YAML peuvent être d’autres pipelines, builds, conteneurs, packages, référentiels ou webhooks.

Après avoir défini une ressource, vous pouvez l’utiliser partout dans votre pipeline. Pour plus d’informations et d’exemples, consultez Définitions de ressources.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

Vous pouvez utiliser l’état de la ressource pour déclencher automatiquement des pipelines en définissant la trigger propriété dans la définition de ressource. Le pipeline resources.triggeringAlias et resources.triggeringCategory les variables sont ensuite définis sur le nom et la catégorie de la ressource. Ces variables sont vides, sauf si la Build.Reason variable est définie sur ResourceTrigger.

Les ressources permettent une traçabilité complète pour les services qu’un pipeline utilise, notamment la version, les artefacts, les validations associées et les éléments de travail. Si vous vous abonnez aux événements déclencheurs sur vos ressources, vous pouvez automatiser entièrement vos flux de travail DevOps.

Autorisation des ressources

Les ressources doivent être autorisées à ê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 les paramètres d’administration de la ressource pour accorder des autorisations d’accès à tous les pipelines. Par exemple, vous pouvez gérer des fichiers sécurisés et des groupes de variables dans la pageBibliothèque de >, ainsi que des pools d’agents et des connexions de service dans lespipelines des > de projet. Cette autorisation est pratique pour les ressources que vous n’avez pas besoin de restreindre, telles que les ressources de test.

• Vérifiez que vous disposez au moins d’un rôle d’utilisateur dans les rôles de sécurité du pool d’agents pour votre projet. Les pipelines YAML que vous créez sont automatiquement autorisés à utiliser des ressources où vous avez un rôle d’utilisateur .

• Si vous ajoutez une définition de ressource à un pipeline YAML, mais que la génération é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, vérifiez que vous avez au moins le rôle d’utilisateur sur la ressource. Vous pouvez ensuite choisir l’option permettant d’autoriser les ressources sur la build ayant échoué. Une fois la ressource autorisée, vous pouvez lancer une nouvelle build.

Vérifications d’approbation pour les ressources

Vous pouvez utiliser des contrôles d’approbation et des modèles pour contrôler manuellement l’utilisation des ressources. En utilisant la vérification d’approbation de modèle requise, vous pouvez exiger tout pipeline qui utilise une ressource ou un environnement spécifique pour s’étendre à partir d’un modèle YAML spécifique.

La définition d’une approbation de modèle requise améliore la sécurité en veillant à ce que votre ressource soit utilisée uniquement dans des conditions spécifiques. Pour plus d’informations, consultez Utiliser des modèles pour la sécurité.

Sélecteur de version de ressource manuelle

Azure Pipelines évalue les versions par défaut des ressources en fonction de leurs définitions de ressources. Pour les exécutions planifiées ou les exécutions manuelles si vous ne choisissez pas manuellement une exécution, Azure Pipelines considère uniquement les exécutions d’intégration continue terminées (CI) correctement effectuées pour évaluer les versions de ressources par défaut.

Vous pouvez utiliser le sélecteur de version de ressource manuelle pour choisir différentes versions de ressources lorsque vous déclenchez manuellement un pipeline de déploiement continu YAML (CD). 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 pipeline les ressources, le sélecteur de versions manuelles vous permet de voir toutes les exécutions disponibles dans toutes les branches, de rechercher les exécutions en fonction du numéro ou de la branche du pipeline, et de choisir une exécution réussie, ayant échoué ou en cours.

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 non lié, avant de pouvoir exécuter votre pipeline CD. Vous avez la possibilité de choisir toute exécution que vous connaissez produit les artefacts dont vous avez besoin.

Pour utiliser le sélecteur de versions de ressource, sélectionnez Ressources dans le volet Exécuter le pipeline , 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, vous pouvez entrer votre version souhaitée dans le champ de texte.

Définitions de ressources

Les ressources de pipeline YAML peuvent être les suivantes :

• Autres pipelines
• Builds
• conteneurs
• Packages
• Référentiels ou
• Webhooks.

Les sections suivantes fournissent des définitions et des exemples des catégories de ressources de pipeline YAML. 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.

Ressource pipelines

Vous pouvez utiliser des ressources CI pipeline comme déclencheurs pour vos flux de travail CD. Vous pouvez également référencer pipeline des ressources à partir de votre pipeline pour télécharger des artefacts ou utiliser des variables de ressources de pipeline. Seuls Azure Pipelines peuvent utiliser la ressource pipelines.

Dans la définition de ressource pipelines :

• pipeline est un nom unique que vous utilisez pour référencer les ressources de pipeline.
• source est le nom du pipeline qui a produit les artefacts de pipeline.

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

Exemples de définitions de ressources de pipeline

L’exemple de définition de ressource suivant utilise des artefacts à partir d’un pipeline au sein du même projet Azure DevOps.

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

Pour spécifier un pipeline à partir d’un autre projet, incluez le project nom dans la définition de ressource. L’exemple suivant utilise branch également pour résoudre la version par défaut lorsque le pipeline est déclenché manuellement ou par planification. L’entrée de branche ne peut pas contenir de caractères génériques.

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

Évaluation de la version des ressources

Azure Pipelines évalue les versions par défaut des ressources en fonction de leurs définitions de ressources. Les versions par défaut de l’artefact de ressource d’un pipeline dépendent de l’exécution manuelle ou planifiée du pipeline ou des déclencheurs en fonction du résultat de l’exécution de la ressource.

Pour une exécution manuelle ou planifiée d’un pipeline, les valeurs des propriétés et version des branchtagsvaleurs de la pipeline définition de ressource définissent les versions d’artefact. L’entrée branch ne peut pas avoir de caractères génériques et les tags propriétés utilisent l’opérateur AND .

Pour les exécutions planifiées ou les exécutions manuelles si vous n’utilisez pas le sélecteur de versions, Azure Pipelines considère uniquement les exécutions d’intégration continue (CI) correctement effectuées lors de l’évaluation des versions de ressources par défaut. Pour les exécutions manuelles, vous pouvez remplacer les versions définies à l’aide du sélecteur de versions manuelles.

Le tableau suivant répertorie les pipeline propriétés de définition de ressource et les versions d’artefact qu’ils spécifient.

La définition de ressource suivante pipeline utilise les propriétés et branch les tags propriétés pour évaluer la version par défaut lorsque le pipeline est planifié ou déclenché manuellement. La myCIAlias version des artefacts est la dernière exécution de build sur la main branche qui a les balises et Production les PreProduction balises.

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

Déclencheurs de ressources de pipeline

Pour les exécutions de pipeline qui se déclenchent sur le résultat d’une exécution de ressource, les trigger paramètres de propriété de la définition de ressource déterminent les versions d’artefact de ressource par défaut. Pour utiliser une pipeline ressource comme déclencheur pour exécuter le pipeline actuel, vous devez définir la trigger propriété. Si vous n’incluez pas de trigger propriété, les exécutions de ressources ne déclenchent pas d’exécutions de pipeline actuelles.

Lorsqu’un pipeline se déclenche en fonction d’une trigger valeur dans une pipeline définition de ressource, les valeurs de la définition versionbranchglobale de ressource et tags les propriétés sont ignorées. Les trigger propriétés déterminent les versions d’artefact.

Le tableau suivant décrit comment les propriétés affectent le comportement du trigger déclencheur.

L’exemple suivant montre une définition de ressource de pipelines avec un simple trigger.

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

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

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    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. Le déclencheur stages utilise l’opérateur AND . Le pipeline CD se déclenche à la fin de toutes les étapes répertoriées.

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

L’exemple suivant utilise tags des filtres pour l’évaluation de version par défaut et pour le déclencheur. Les trigger balises utilisent l’opérateur AND . L’ensemble tags dans pipeline les définitions de ressources est différent des balises définies sur les branches du référentiel Git.

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

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

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

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

Téléchargement d’artefacts de pipeline

Vous pouvez utiliser l’étape download d’un pipeline YAML pour télécharger des artefacts associés à l’exécution actuelle ou à une autre pipeline ressource.

Les artefacts téléchargent automatiquement uniquement dans les travaux de déploiement. Tous les artefacts du pipeline actuel et toutes ses pipeline ressources sont automatiquement téléchargés et disponibles au début de chaque travail de déploiement. Vous pouvez remplacer ce comportement en définissant download sur none, ou en spécifiant un autre pipeline identificateur de ressource.

Dans un travail de génération standard, les artefacts ne sont pas téléchargés automatiquement. Utilisez download explicitement si nécessaire.

À l’étape download , la propriété facultative artifact spécifie les noms d’artefacts. S’il 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 à télécharger. 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'

Artefacts à partir du téléchargement de la pipeline ressource vers $(PIPELINE). WORKSPACE)/<pipeline-identifier/>dossier artifact-identifier<>. Pour plus d’informations, veuillez consulter la section Publier et télécharger des artefacts de pipeline. Pour un autre moyen de télécharger des artefacts de pipeline, veuillez consulter la section Télécharger des artefacts.

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érer la ressource

Si vous disposez d’un système de génération CI qui produit des artefacts, vous pouvez utiliser les artefacts avec builds des ressources.

La catégorie builds est extensible. Une ressource build peut provenir de n’importe quel système CI externe comme Jenkins, TeamCity ou CircleCI. Vous pouvez utiliser builds pour écrire une extension pour consommer des artefacts à partir de votre service de build ou introduire un nouveau type de service.

Dans la définition de build, version est par défaut la dernière build réussie. Vous devez définir trigger explicitement si vous le souhaitez. Pour obtenir des informations de schéma complètes, consultez la définition resources.builds.build .

Dans l’exemple suivant, Jenkins est le type de ressource.

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

La tâche downloadBuild

Les build artefacts de ressources ne sont pas téléchargés automatiquement vers des travaux/deploy-jobs. 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.

La downloadBuild 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. Artefacts à partir du téléchargement de la build ressource vers $(PIPELINE). WORKSPACE)/<build-identifier>/ dossier.

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. S’il n’est pas spécifié, tous les artefacts associés au téléchargement de la ressource.

La propriété optionnelle patterns définit un chemin minimatch ou une liste de chemins minimatch à télécharger. S’il est vide, l’ensemble de l’artefact est téléchargé. L’exemple 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 .

Ressource référentiels

Utilisez le repository mot clé pour informer le système des dépôts externes si :

• Votre pipeline a des modèles dans un autre référentiel.
• Vous souhaitez utiliser l’extraction de plusieurs référentiels avec un référentiel qui nécessite une connexion de service.

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 gittypes , github, githubenterpriseet bitbucket les types de référentiels.

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

Le tableau suivant décrit les types de repository ressources :

Variables de ressource de référentiel

resources.repositories.<alias>.name
resources.repositories.<alias>.ref
resources.repositories.<alias>.type
resources.repositories.<alias>.id
resources.repositories.<alias>.url

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"

resources.repositories.<alias>.name
resources.repositories.<alias>.ref
resources.repositories.<alias>.type
resources.repositories.<alias>.id
resources.repositories.<alias>.url
resources.repositories.<alias>.version

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

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

Les référentiels de la ressource repository ne sont pas synchronisés automatiquement dans vos travaux. Vous pouvez utiliser le checkout mot clé pour extraire un référentiel défini dans une repository ressource. Pour plus d’informations, consultez Utiliser plusieurs référentiels dans votre pipeline. Pour obtenir des informations de schéma complètes, consultez la définition steps.checkout .

Ressource conteneurs

Vous pouvez utiliser containers des ressources pour consommer des images conteneur dans vos pipelines CI/CD. Une ressource container peut être un registre Docker public ou privé ou une instance d’Azure Container Registry.

Vous pouvez utiliser une image de ressource conteneur générique dans le cadre de vos travaux ou l’utiliser dans les travaux de conteneur. Si votre pipeline nécessite la prise en charge d’un ou plusieurs services, vous devez également créer et vous connecter à des conteneurs de service. Vous pouvez utiliser des volumes pour partager des données entre les services.

Si vous avez besoin d’utiliser des images à partir d’un registre Docker, vous pouvez définir une ressource de conteneur générique sans utiliser de type mot clé. 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 .

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 vos travaux et activer les déclencheurs de pipeline automatique.

Vous avez besoin des autorisations Contributeur ou Propriétaire d’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 type de ressource acr, vous devez spécifier les valeurs azureSubscription, resourceGroup, et repository pour votre registre de conteneurs Azure. Par exemple :

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

Variables de ressources de conteneur

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

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

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

resources:
  containers:
  - container: mycontainer
    type: acr
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

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

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

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

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. Azure Pipelines affiche les informations suivantes pour chaque exécution de pipeline qui utilise des ressources :

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

Informations de pipeline CD associées pour les pipelines CI

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

Traçabilité de l’environnement

Une fois qu’un pipeline est déployé dans un environnement, vous pouvez voir la liste des ressources qu’il a consommées et leurs commits et éléments de travail associés.

Questions fréquentes (FAQ)

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

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

Vous pouvez utiliser le raccourci download pour télécharger les artefacts dans les tâches de build ou pour remplacer le comportement de téléchargement dans les tâches de déploiement. Pour plus d’informations, consultez la 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 mise en production 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.

Pourquoi mon déclencheur de ressource n’a-t-il pas fonctionné ?

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

• La source de la connexion de service fournie n’est pas valide.
• Le déclencheur n’est pas configuré ou il existe des erreurs de syntaxe dans le déclencheur.
• 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. Les problèmes de déclencheur ne sont pas disponibles pour les ressources du référentiel.

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

Contenu connexe

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