Définir des ressources dans YAML

  • Article

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

Les ressources dans YAML représentent des sources de pipelines, de builds, de référentiels, de conteneurs, de packages et de webhooks. Les ressources vous fournissent également la traçabilité complète des services utilisés dans votre pipeline, notamment la version, les artefacts, les commits associés et les éléments de travail. Lorsque vous définissez une ressource, elle peut être consommée n’importe où dans votre pipeline. Vous pouvez également automatiser entièrement votre workflow DevOps en vous abonnant pour déclencher des événements sur vos ressources.

Pour plus d’informations, consultez À propos des ressources et de la définition de schéma YAML des ressources.

schéma

resources:
  pipelines: [ pipeline ]  
  builds: [ build ]
  repositories: [ repository ]
  containers: [ container ]
  packages: [ package ]
  webhooks: [ webhook ]

Variables

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

resources.triggeringAlias
resources.triggeringCategory

Ces valeurs sont vides si une ressource ne déclenche pas d’exécution de pipeline. La variable Build.Reason doit être ResourceTrigger pour que ces valeurs soient définies.

Définir une ressource pipelines

Si vous avez un pipeline qui produit des artefacts, vous pouvez utiliser les artefacts en définissant une ressource pipelines. pipelines est une ressource dédiée uniquement pour Azure Pipelines. Vous pouvez également définir des déclencheurs sur une ressource de pipeline pour vos flux de travail CD.

Dans votre définition de ressource, pipeline est une valeur unique que vous pouvez utiliser pour référencer ultérieurement la ressource de pipeline. source est le nom du pipeline qui produit un artefact. Utilisez l’étiquette définie par pipeline pour référencer la ressource de pipeline à partir d’autres parties du pipeline, par exemple lors de l’utilisation de variables de ressource de pipeline ou du téléchargement d’artefacts.

Pour obtenir une autre façon de télécharger des pipelines, consultez les tâches dans Artefacts de pipeline.

resources:        # types: pipelines | builds | repositories | containers | packages
  pipelines:
  - pipeline: string  # identifier for the resource used in pipeline resource variables
    project: string # project for the source; optional for current project
    source: string  # name of the pipeline that produces an artifact. If it is in a different pipelines folder, it needs to be the full path, e.g. MyTeam/MyPipeline
    version: string  # the pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; Used only for manual or scheduled triggers
    branch: string  # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
    tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
    trigger:     # triggers aren't enabled by default unless you add trigger section to the resource
      branches:  # branch conditions to filter the events, optional; Defaults to all branches.
        include: [ string ]  # branches to consider the trigger events, optional; Defaults to all branches.
        exclude: [ string ]  # branches to discard the trigger events, optional; Defaults to none.
      tags: [ string ]  # list of tags to evaluate for trigger event, optional
      stages: [ string ] # list of stages to evaluate for trigger event, optional

Important

Lorsque vous définissez un déclencheur de ressource, si sa ressource de pipeline provient du même référentiel (par exemple, autonome) que le pipeline actuel, le déclenchement suit la branche et la validation sur lesquelles l’événement est déclenché. Toutefois, si la ressource de pipeline provient d’un autre référentiel, le pipeline actuel se déclenche sur le branche par défaut du référentiel autonome.

Évaluation de la version de l’artefact

La version des artefacts du pipeline de ressources dépend de la façon dont votre pipeline est déclenché.

Si votre pipeline s’exécute parce que vous l’avez déclenché manuellement ou en raison d’une exécution planifiée, la version de la version des artefacts est définie par les valeurs des propriétés version, branchet tags.

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

Prenons un exemple. Supposons que votre pipeline contient la définition de ressource suivante.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main      ### This branch input cannot have wild cards. It is used for evaluating default version when pipeline is triggered manually or scheduled.
    tags:               ### These tags are used for resolving default version when the pipeline is triggered manually or scheduled
    - Production        ### Tags are AND'ed
    - PreProduction

Lorsque vous déclenchez manuellement l’exécution de votre pipeline, la version des artefacts du pipeline MyCIAlias est l’un des derniers builds effectués sur la branche main et qui contient les balises Production et PrepProduction.

Lorsque votre pipeline est déclenché parce que l’un de ses pipelines de ressources se termine, la version des artefacts est celle 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 du pipeline actuel est déclenchée chaque fois que le pipeline de ressources termine correctement une exécution sur les branches include
tags Une nouvelle exécution du pipeline actuel est déclenchée 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 du pipeline actuel est déclenchée chaque fois que le pipeline de ressources termine correctement une exécution des stages spécifiés
branches, tags et stages Une nouvelle exécution du pipeline actuel est déclenchée chaque fois que l’exécution du pipeline de ressources satisfait à toutes les conditions de branche, de balise et d’index
trigger: true Une nouvelle exécution du pipeline actuel est déclenchée chaque fois que le pipeline de ressources termine correctement une exécution
Rien Aucune nouvelle exécution du pipeline actuel n’est déclenchée quand le pipeline de ressources termine correctement une exécution

Prenons un exemple. Supposons que votre pipeline contient la définition de ressource suivante.

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

Votre pipeline s’exécute chaque fois que les pipelines SmartHotel-CI s’exécutent sur l’une des branches releases ou sur la branche main, sont marqués à la fois avec Verified et Signed, et ont terminé les index Production et PreProduction.

download pour les pipelines

Tous les artefacts du pipeline actuel et de toutes les ressources pipeline sont automatiquement téléchargés et mis à disposition au début de chaque travail deployment. Vous pouvez écraser ce comportement. Pour plus d’informations, consultez Artefacts de pipeline. Les artefacts 'job' standard ne sont pas téléchargés automatiquement. Utilisez download explicitement si nécessaire.

steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
  artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
  patterns: string # patterns representing files to include; optional

Les artefacts de la ressource pipeline sont téléchargés dans le dossier $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>.

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. L’<Alias> est l’identificateur que vous avez donné pour votre ressource de pipeline. Les variables de ressources de pipeline sont disponibles uniquement au moment de l’exécution.

Pour en savoir plus sur la syntaxe des variables, consultez Définir des variables.

resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

Pour plus d’informations, consultez Métadonnées de ressources de pipeline en tant que variables prédéfinies.

Définir une ressource builds

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

resources:        # types: pipelines | builds | repositories | containers | packages
  builds:
  - build: string   # identifier for the build resource
    type: string   # the type of your build service like Jenkins, circleCI etc.
    connection: string   # service connection for your build service.
    source: string   # source definition of the build
    version: string   # the build number to pick the artifact, defaults to Latest successful build
    trigger: boolean    # Triggers aren't enabled by default and should be explicitly set

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

Important

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

Tâche downloadBuild pour les builds

Vous pouvez consommer des artefacts de la ressource build dans le cadre de vos travaux à l’aide de la tâche downloadBuild. En fonction du type de ressource build défini, cette tâche est automatiquement résolue en tâche de téléchargement correspondante pour le service pendant l’exécution.

Les artefacts de la ressource build sont téléchargés dans le dossier $(PIPELINE.WORKSPACE)/<build-identifier>/.

Important

Les artefacts de la ressource build ne sont pas automatiquement téléchargés dans vos travaux/travaux de déploiement. Vous devez ajouter explicitement la tâche downloadBuild pour consommer les artefacts.

- downloadBuild: string # identifier for the resource from which to download artifacts
  artifact: string # artifact to download; if left blank, downloads all artifacts associated with the resource provided
  patterns: string | [ string ] # a minimatch path or list of [minimatch paths](tasks/file-matching-patterns.md) to download; if blank, the entire artifact is downloaded

Définir une ressource repositories

Si votre pipeline a des modèles dans un autre référentiel, ou si vous souhaitez utiliser l’extraction multi-référentiel avec un référentiel qui nécessite une connexion de service, vous devez informer le système de ce référentiel. Le mot clé repository vous permet de spécifier un dépôt externe.

resources:
    repositories:
    - repository: string # Required as first property. Alias for the repository.
      endpoint: string # ID of the service endpoint connecting to this repository.
      trigger: none | trigger | [ string ] # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos).
      name: string # repository name (format depends on 'type'; does not accept variables).
      ref: string # ref name to checkout; defaults to 'refs/heads/main'. The branch checked out by default whenever the resource trigger fires.
      type: string # Type of repository: git, github, githubenterprise, and bitbucket.

Type

Les pipelines prennent 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.

Type spécifié Résultat Exemple
type: git La valeur name fait référence à un autre référentiel dans le même projet. name: otherRepo Pour faire référence à un référentiel dans un autre projet au sein de la même organisation, préfixez le nom de ce projet. par exemple name: OtherProject/otherRepo.
type: github La valeur name est le nom complet du référentiel GitHub et inclut l’utilisateur ou l’organisation. name: Microsoft/vscode
type: githubenterprise La valeur name est le nom complet du référentiel GitHub Enterprise et inclut l’utilisateur ou l’organisation. name: Microsoft/vscode
type: bitbucket La valeur name est le nom complet du référentiel Bitbucket Cloud et inclut l’utilisateur ou l’organisation. name: MyBitbucket/vscode

Les référentiels GitHub Enterprise nécessitent une connexion de service GitHub Enterprise pour l’autorisation.

Les référentiels Bitbucket Cloud nécessitent une connexion au service Bitbucket Cloud pour l’autorisation.

Variables

Dans chaque exécution, les métadonnées d’une ressource de référentiel sont disponibles pour tous les travaux en tant que variables de runtime. L’<Alias> est l’identificateur que vous avez donné pour 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

Variables

Dans chaque exécution, les métadonnées d’une ressource de référentiel sont disponibles pour tous les travaux en tant que variables de runtime. L’<Alias> est l’identificateur que vous avez donné pour 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

Utiliser checkout pour consommer le référentiel

Utilisez le mot clé checkout pour consommer vos référentiels définis dans le cadre d’une ressource repository.

schéma

steps:
- checkout: string # Required as first property. Configures checkout for the specified repository.
  clean: string # If true, run git clean -ffdx followed by git reset --hard HEAD before fetching.
  fetchDepth: string # Depth of Git graph to fetch.
  fetchTags: string # Set to 'true' to sync tags when fetching the repo, or 'false' to not sync tags. See remarks for the default behavior.
  lfs: string # Set to 'true' to download Git-LFS files. Default is not to download them.
  persistCredentials: string # Set to 'true' to leave the OAuth token in the Git config after the initial fetch. The default is not to leave it.
  submodules: string # Set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules. Default is not to fetch submodules.
  path: string # Where to put the repository. The default is $(Build.SourcesDirectory).
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Les référentiels de la ressource repository ne sont pas synchronisés automatiquement dans vos travaux. Utilisez checkout pour récupérer vos référentiels dans le cadre de vos travaux.

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

Définir une ressource containers

Si vous devez consommer une image conteneur dans le cadre de votre pipeline d’intégration continue/livraison continue (CI/CD), vous pouvez l’obtenir à l’aide de containers. Une ressource de conteneur peut être un registre Docker public ou privé, ou Azure Container Registry.

Si vous devez consommer des images à partir du registre Docker dans le cadre de votre pipeline, vous pouvez définir une ressource de conteneur générique (le mot clé type n’est pas obligatoire).

resources:
  containers:
  - container: string  # identifier (A-Z, a-z, 0-9, and underscore)
    image: string  # container image name
    options: string  # arguments to pass to container at startup
    endpoint: string  # reference to a service connection for the private registry
    env: { string: string }  # list of environment variables to add
    ports: [ string ] # ports to expose on the container
    volumes: [ string ] # volumes to mount on the container
    mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
    mountReadOnly:  # volumes to mount read-only - all default to false
      externals: boolean  # components required to talk to the agent
      tasks: boolean  # tasks required by the job
      tools: boolean  # installable tools like Python and Ruby
      work: boolean # the work directory

Vous pouvez utiliser une ressource de conteneur générique comme image consommée dans le cadre de votre travail. Elle peut également être utilisée pour les travaux de conteneur. Si votre pipeline nécessite la prise en charge d’un ou plusieurs services, vous devez créer des conteneurs de service et vous y connecter. Vous pouvez utiliser des volumes pour partager des données entre des services.

Vous pouvez utiliser un type de ressource conteneur de première classe pour Azure Container Registry (ACR) afin de consommer vos images ACR. Ce type de ressources peut être utilisé dans le cadre de vos travaux, ainsi que pour activer les déclencheurs de pipeline automatiques. Vous devez disposer des autorisations Contributeur ou Propriétaire pour qu’ACR utilise des déclencheurs de pipeline automatiques. Pour plus d’informations, consultez Rôles et autorisations Azure Container Registry.

resources:          # types: pipelines | repositories | containers | builds | packages
  containers:
  - container: string # identifier for the container resource      
    type: string # type of the registry like ACR, GCR etc. 
    azureSubscription: string # Azure subscription (ARM service connection) for container registry;
    resourceGroup: string # resource group for your ACR
    registry: string # registry for container images
    repository: string # name of the container image repository in ACR
    trigger: # Triggers aren't enabled by default and need to be set explicitly
      enabled: boolean # set to 'true' to trigger on all image tags if 'tags' is unset.
      tags:
        include: [ string ]  # image tags to consider the trigger events, optional; defaults to any new tag
        exclude: [ string ]  # image tags on discard the trigger events, optional; defaults to none

Notes

La syntaxe utilisée pour activer les déclencheurs de conteneur pour toutes les balises d’image (enabled: 'true') est différente de la syntaxe utilisée pour les autres déclencheurs de ressources. Faites particulièrement attention à utiliser la syntaxe correcte pour une ressource spécifique.

Remarque

Les connexions de service qui utilisent la fédération des identités 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 de conteneur sont transmises au pipeline sous la forme de variables. Des informations telles que l’image, le registre et les détails de connexion sont accessibles dans tous les travaux à utiliser 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.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

La variable d’emplacement s’applique uniquement au type ACR de ressources de conteneur.

Définir une ressource packages

Vous pouvez utiliser des packages GitHub NuGet et npm en tant que ressource dans des pipelines YAML.

Lorsque vous spécifiez des ressources package, définissez le package sur NuGet ou npm. Vous pouvez également activer les déclencheurs de pipeline automatisés lorsqu’une nouvelle version de package est publiée.

Pour utiliser des packages GitHub, utilisez l’authentification basée sur un jeton d’accès personnel (PAT) et créez une connexion de service GitHub qui utilise des PAT.

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

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConnectionName # GitHub service connection with the PAT type
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.1 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Définir une ressource webhooks

Notes

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

Avec d’autres ressources (telles que les pipelines, les conteneurs, le build et les packages), vous pouvez consommer des artefacts et activer des déclencheurs automatisés. Toutefois, vous ne pouvez pas automatiser votre processus de déploiement en fonction d’autres événements ou services externes. La ressource webhooks vous permet d’intégrer votre pipeline à n’importe quel service externe et d’automatiser le workflow. Vous pouvez vous abonner à n’importe quel événement externe via ses webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory, etc.) et déclencher vos pipelines.

Effectuez les étapes suivantes pour configurer les déclencheurs de webhook.

  1. Configurez un webhook sur votre service externe. Lorsque vous créez votre webhook, vous devez fournir les informations suivantes :

    • URL de la requête

      https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview

    • Secret : Facultatif. Si vous devez sécuriser votre charge utile JSON, indiquez la valeur Secret.

  2. Créez une connexion de service « Webhook entrant ». Cette connexion est un type de connexion de service nouvellement introduit qui vous permet de définir les informations importantes suivantes :

    • Nom du webhook : le nom du webhook doit correspondre au webhook créé dans votre service externe.
    • En-tête HTTP : nom de l’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 requête. Par exemple, pour GitHub, l’en-tête de requête est « X-Hub-Signature ».
    • Secret : le secret est utilisé pour vérifier le hachage HMAC-SHA1 de la charge utile utilisé pour la vérification de la requête entrante (facultatif). Si vous avez utilisé un secret lors de la création de votre webhook, vous devez fournir la même clé secrète.

    Connexion de service « Webhook entrant »

  3. Un nouveau type de ressource appelé webhooks est introduit dans les pipelines YAML. Pour vous abonner à un événement webhook, définissez une ressource webhook dans votre pipeline et pointez-la vers la connexion du service webhook entrant. Vous pouvez également définir d’autres filtres sur la ressource webhook, en fonction des données de charge utile JSON, pour personnaliser les déclencheurs pour chaque pipeline. Consommez les données de charge utile sous la forme de variables dans vos travaux.

  4. Chaque fois que la connexion de service Webhook entrant reçoit un événement webhook, une nouvelle exécution est déclenchée pour tous les pipelines abonnés à l’événement webhook. Vous pouvez utiliser les données de charge utile JSON dans vos travaux à l’aide du format ${{ parameters.<WebhookAlias>.<JSONPath>}}

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias           ### Webhook alias
      connection: IncomingWebhookConnection    ### Incoming webhook service connection
      filters:                                 ### List of JSON parameters to filter; Parameters are AND'ed
        - path: JSONParameterPath              ### JSON path in the payload
          value: JSONParameterExpectedValue    ### Expected value in the path provided

Les webhooks automatisent votre flux de travail en fonction de tout événement webhook externe qui n'est pas pris en charge par les ressources de première classe, comme les pipelines, les builds, les conteneurs et les paquets. En outre, pour les services locaux pour lesquels Azure DevOps n’a pas de visibilité sur le processus, vous pouvez configurer des webhooks sur le service et déclencher automatiquement vos pipelines.

Sélecteur de version manuelle pour les ressources dans la boîte de dialogue Créer une exécution

Lorsque vous déclenchez manuellement un pipeline CD YAML, nous évaluons automatiquement la version par défaut des ressources définies dans le pipeline, en fonction des entrées fournies. Toutefois, vous pouvez décider de choisir une autre version à partir du sélecteur de version de ressource lorsque vous créez une exécution.

  1. Dans le volet Créer une exécution, sélectionnez Ressources. Une liste des ressources consommées dans ce pipeline s’affiche.

  2. Sélectionnez une ressource et choisissez une version spécifique dans la liste des versions disponibles. Le sélecteur de version de ressources est pris en charge pour les ressources de pipeline, de build, de référentiel, de conteneur et de package.

    Sélecteur de version de pipeline

Pour les ressources de pipeline, vous pouvez voir toutes les exécutions disponibles sur toutes les branches. Recherchez-les en fonction du numéro de pipeline ou de la branche. Choisissez ensuite une exécution réussie, qui a échoué ou qui est en cours. Cette flexibilité vous permet d’exécuter votre pipeline CD si vous êtes sûr qu’il a produit tous les artefacts dont vous avez besoin. Vous n’avez pas besoin d’attendre la fin ou la réexécution de l’exécution CI en raison d’un échec d’index non lié dans l’exécution CI. Toutefois, nous considérons les exécutions CI réussies uniquement lorsque nous évaluons la version par défaut des déclencheurs planifiés, ou si vous n’utilisez pas de sélecteur de version manuel.

Pour les ressources dans lesquelles vous ne pouvez pas extraire les versions disponibles, comme les packages GitHub, nous affichons une zone de texte dans le sélecteur de version afin que vous puissiez fournir la version que l’exécution doit choisir.

Autoriser un pipeline YAML

Les ressources doivent être autorisées avant de pouvoir être utilisées. Un propriétaire de ressource contrôle les utilisateurs et les pipelines qui peuvent accéder à cette ressource. Le pipeline doit être autorisé à utiliser la ressource. Consultez les méthodes suivantes permettant d’autoriser un pipeline YAML.

  • Accédez à l’expérience d’administration de 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. Les pools d’agents et les connexions de service sont gérés dans Paramètres du projet. Ici, vous pouvez autoriser tous les pipelines à accéder à cette ressource. Cette autorisation est pratique si vous n’avez pas besoin de restreindre l’accès à une ressource, par exemple, des ressources de test.

  • Lorsque vous créez un pipeline pour la première fois, toutes les ressources référencées dans le fichier YAML sont automatiquement autorisées à être utilisées par le pipeline, si vous êtes membre du rôle Utilisateur pour cette ressource. Ainsi, les ressources référencées dans le fichier YAML lorsque vous créez un pipeline sont automatiquement autorisées.

  • Lorsque vous apportez des modifications au fichier YAML et ajoutez des ressources, le build échoue avec une erreur similaire à l’erreur suivante : Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.

    Dans ce cas, vous voyez une option permettant d’autoriser les ressources sur le build ayant échoué. Si vous êtes membre du rôle Utilisateur de la ressource, vous pouvez sélectionner cette option. Une fois les ressources autorisées, vous pouvez démarrer un nouveau build.

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

Définir des vérifications d’approbation pour les ressources

Vous pouvez contrôler manuellement quand une ressource s’exécute avec des contrôles et des modèles d’approbation. Avec le contrôle d’approbation de modèle requis, vous pouvez exiger n’importe quel pipeline utilisant une ressource ou un environnement qui s’étend également à partir d’un modèle YAML spécifique. Paramétrer une approbation de modèle requise améliore la sécurité. Assurez-vous que votre ressource est utilisée uniquement dans des conditions spécifiques avec un modèle. Découvrez comment améliorer la sécurité du pipeline avec des modèles et des ressources.

Traçabilité

Nous fournissons 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

Pour chaque exécution de pipeline, nous affichons les informations suivantes.

  • Ressource qui a déclenché le pipeline, s’il est déclenché par une ressource.

    Déclencheur de ressource dans un pipeline

  • Version de la ressource et des artefacts consommés.

    Artefacts consommés lors de l’exécution du pipeline

  • Validations associées à chaque ressource.

    Validations lors de l’exécution du pipeline

  • É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 suivante inclut les ressources consommées dans le cadre des travaux de déploiement, ainsi que les validations et les éléments de travail associés.

Validations dans l’environnement

Afficher les 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 donnant. Vous pouvez voir la liste des exécutions de pipelines CD YAML lors desquelles une exécution de pipeline CI est consommée via la ressource pipeline. Si d’autres pipelines consomment votre pipeline CI, vous voyez un onglet « Pipelines associés » dans la vue d’exécution. Vous trouverez ici toutes les exécutions de pipeline qui consomment votre pipeline et les artefacts qu’il contient.

Informations sur les pipelines CD dans un pipeline CI

Prise en charge et traçabilité des problèmes de déclencheur de ressource YAML

Cela peut être déroutant lorsque les déclencheurs de pipeline ne parviennent pas à s’exécuter. Nous avons ajouté un nouvel élément de menu dans la page de définition de pipeline, appelé Problèmes de déclenchement, dans lequel vous pouvez découvrir pourquoi les déclencheurs ne s’exécutent pas. Pour accéder à cette page, ouvrez l’historique de votre pipeline. Problèmes de déclenchement est disponible uniquement pour les ressources autres que les référentiels.

Sélectionner des problèmes de déclenchement dans le volet de navigation.

Les déclencheurs de ressources peuvent ne pas s’exécuter pour les raisons suivantes.

  • Si la source de la connexion de service fournie n’est pas valide ou s’il existe des erreurs de syntaxe dans le déclencheur, celui-ci n’est pas configuré, ce qui entraîne une erreur.

  • Si les conditions de déclenchement ne sont pas mises en correspondance, le déclencheur ne s’exécute pas. Un avertissement est mis en évidence afin que vous puissiez comprendre pourquoi les conditions n’ont pas été mises en correspondance.

    Prise en charge des problèmes de déclenchement

Étapes suivantes

Ajouter et utiliser des groupes de variables

Forum aux questions

Pourquoi utiliser des pipelines resources au lieu du raccourci download ?

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 choisir de télécharger les artefacts dans les travaux de génération ou de remplacer le comportement de téléchargement dans les travaux de déploiement par download. Pour plus d’informations, consultez steps.download.

Pourquoi utiliser resources au lieu de la tâche Télécharger les artefacts de pipeline ?

Lorsque vous utilisez directement la tâche Télécharger les artefacts de pipeline, vous ne disposez pas de la traçabilité et des déclencheurs. Il est parfois judicieux d’utiliser directement la tâche Télécharger les artefacts de pipeline. Par exemple, vous pouvez avoir une tâche de script enregistrée dans un modèle différent et celle-ci nécessite le téléchargement d’artefacts d’un build. Ou alors, vous ne savez peut-être pas si une personne qui utilise un modèle souhaite ajouter une ressource de pipeline. 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 ?

Vous devez configurer un pipeline de mise en production classique, car le déclencheur de ressource conteneurs n’est pas disponible pour Docker Hub pour les pipelines YAML.

  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. Sélectionnez l’espace de noms, le référentiel, la version et l’alias source.

    Ajouter un artefact Docker Hub.

  3. Sélectionnez le déclencheur et basculez le déclencheur de déploiement continu sur Activer. Vous allez créer une mise en production chaque fois qu’un envoi Docker se produit dans le référentiel sélectionné.

  4. Créez un nouvel index et un nouveau travail. Ajoutez deux tâches, connexion Docker et Bash :

  • La tâche Docker a l’action login et vous permet de vous connecter à Docker Hub.

  • La tâche Bash exécute docker pull <hub-user>/<repo-name>[:<tag>]. Remplacez hub-user, repo-name et tag par vos valeurs.

    Ajouter une connexion Docket et des tâches Bash.

Comment puis-je valider et dépanner les webhooks ?

  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. Lorsque vous exécutez 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 de code d’état de 500 avec l’erreur Cannot find webhook for the given webHookId ..., votre code peut se trouver dans une branche qui n’est pas votre branche par défaut.

    1. Ouvrez votre pipeline.
    2. Sélectionnez Modifier.
    3. Sélectionnez le menu Plus d’actions Sélectionnez le menu Plus d’actions.
    4. Sélectionnez Déclencheurs>YAML>Obtenir les sources.
    5. Accédez à Branche par défaut pour les builds manuels et planifiés pour mettre à jour votre branche de fonctionnalité.
    6. Sélectionnez Enregistrer et mettre en file d’attente.
    7. 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.