Partager via

Générer des dépôts Git Azure Repos ou Git TFS

  • Article

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

Azure Pipelines peut automatiquement générer et valider chaque demande de tirage (pull request) et effectuer un commit dans votre dépôt Git Azure Repos.

Choisir un dépôt à générer

Vous créez un pipeline en sélectionnant d’abord un dépôt, puis un fichier YAML dans ce dépôt. Le dépôt dans lequel le fichier YAML est présent est appelé dépôt self. Par défaut, il s’agit du dépôt que votre pipeline génère.

Vous pouvez configurer ultérieurement votre pipeline pour extraire un autre référentiel ou plusieurs référentiels. Pour savoir comment procéder, consultez Extraction de plusieurs dépôts.

Azure Pipelines doit avoir accès à vos dépôts pour déclencher leurs générations et extraire leur code pendant les générations. Normalement, un pipeline a accès aux dépôts du même projet. Toutefois, si vous voulez accéder aux dépôts dans un autre projet, vous devez mettre à jour les autorisations accordées aux jetons d’accès du travail.

Déclencheurs CI

Les déclencheurs d’intégration continue (CI) entraînent l’exécution d’un pipeline chaque fois que vous envoyez une mise à jour aux branches spécifiées ou que vous envoyez des étiquettes spécifiées.

Les pipelines YAML sont configurés par défaut avec un déclencheur CI sur toutes les branches, sauf si le paramètre Désactiver le déclencheur YAML CI implicite, introduit dans Azure DevOps sprint 227, est activé. Le paramètre Désactiver le déclencheur YAML CI implicite peut être configuré au niveau de l’organisation ou au niveau du projet. Lorsque le paramètre Désactiver le déclencheur YAML CI implicite est activé, les déclencheurs CI pour les pipelines YAML ne sont pas activés si le pipeline YAML n’a pas de section trigger. Par défaut, Désactiver le déclencheur YAML CI implicite n’est pas activé.

Branches

Vous pouvez contrôler les branches qui obtiennent des déclencheurs CI avec une syntaxe simple :

trigger:
- main
- releases/*

Vous pouvez spécifier le nom complet de la branche (par exemple, main) ou un caractère générique (par exemple, releases/*). Pour plus d’informations sur la syntaxe des caractères génériques, consultez Caractères génériques.

Notes

Vous ne pouvez pas utiliser des variables dans les déclencheurs, car les variables sont évaluées au moment de l’exécution (après le déclenchement du déclencheur).

Notes

Si vous utilisez des modèles pour créer des fichiers YAML, vous pouvez uniquement spécifier des déclencheurs dans le fichier YAML principal du pipeline. Vous ne pouvez pas spécifier de déclencheurs dans les fichiers de modèle.

Pour les déclencheurs plus complexes qui utilisent exclude ou batch, vous devez utiliser la syntaxe complète, comme indiqué dans l’exemple suivant.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

Dans l’exemple ci-dessus, le pipeline est déclenché si une modification est envoyée vers main ou une branche de mise en production. Toutefois, il ne sera pas déclenché si une modification est apportée à une branche de mise en production qui commence par old.

Si vous spécifiez une clause exclude sans clause include, cela équivaut à spécifier * dans la clause include.

En plus de spécifier des noms de branches dans les listes branches, vous pouvez également configurer des déclencheurs basés sur des étiquettes en utilisant le format suivant :

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Si vous n’avez pas spécifié de déclencheurs et que le paramètre Désactiver le déclencheur YAML CI implicite n’est pas activé, la valeur par défaut est la suivante :

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Important

Lorsque vous spécifiez un déclencheur, il remplace le déclencheur implicite par défaut, et seuls les envois aux branches explicitement configurées pour être incluses déclenchent un pipeline. Les inclusions sont d’abord traitées, puis les exclusions sont supprimées de cette liste.

Traitement par lot d’exécutions d’intégration continue

Si de nombreux membres de l’équipe chargent souvent des modifications, vous pouvez réduire le nombre d’exécutions que vous démarrez. Si vous définissez batch sur true, lorsqu’un pipeline est en cours d’exécution, le système attend que l’exécution soit terminée, puis démarre une autre exécution avec toutes les modifications qui n’ont pas encore été générées.

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Notes

batch n’est pas pris en charge dans les déclencheurs de ressources de dépôt.

Pour clarifier cet exemple, supposons qu’un envoi A à main a provoqué l’exécution du pipeline ci-dessus. Pendant que ce pipeline est en cours d’exécution, d’autres envois B et C se produisent dans le dépôt. Ces mises à jour ne démarrent pas immédiatement de nouvelles exécutions indépendantes. Mais une fois la première exécution terminée, tous les envois jusqu’à ce point de temps sont regroupés, et une nouvelle exécution est démarrée.

Notes

Si le pipeline comporte plusieurs travaux et phases, la première exécution doit toujours atteindre un état terminal en achevant ou en ignorant tous ses travaux et phases avant le démarrage de la deuxième exécution. Pour cette raison, vous devez faire preuve de prudence lorsque vous utilisez cette fonctionnalité dans un pipeline avec plusieurs phases ou approbations. Si vous souhaitez traiter vos builds par lot dans de tels cas, il est recommandé de fractionner votre processus CI/CD en deux pipelines : un pour les builds (avec traitement par lot) et l’autre pour les déploiements.

Chemins

Vous pouvez spécifier des chemins d’accès aux fichiers à inclure ou à exclure.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Lorsque vous spécifiez des chemins d’accès, vous devez spécifier explicitement les branches sur lesquelles se déclencher si vous utilisez Azure DevOps Server 2019.1 ou une version antérieure. Vous ne pouvez pas déclencher un pipeline avec uniquement un filtre de chemin d’accès ; vous devez également disposer d’un filtre de branche, et les fichiers modifiés qui correspondent au filtre de chemin d’accès doivent provenir d’une branche qui correspond au filtre de branche. Si vous utilisez Azure DevOps Server 2020 ou une version ultérieure, vous pouvez omettre branches pour filtrer sur toutes les branches conjointement avec le filtre de chemin d’accès.

Les caractères génériques sont pris en charge pour les filtres de chemin. Par exemple, vous pouvez inclure tous les chemins qui correspondent à src/app/**/myapp*. Vous pouvez utiliser des caractères carte génériques (**, * ou ?)) lorsque vous spécifiez des filtres de chemin d’accès.

  • Les chemins d’accès sont toujours spécifiés par rapport à la racine du dépôt.
  • Si vous ne définissez pas de filtres de chemin d’accès, le dossier racine du dépôt est implicitement inclus par défaut.
  • Si vous excluez un chemin d’accès, vous ne pouvez pas l’inclure, sauf si vous le qualifiez pour un dossier plus profond. Par exemple, si vous excluez /tools, vous pouvez inclure /tools/trigger-runs-on-these
  • L’ordre des filtres de chemin d’accès n’a pas d’importance.
  • Les chemins d’accès dans Git respectent la casse. Veillez à utiliser la même casse que les dossiers réels.
  • Vous ne pouvez pas utiliser des variables dans les chemins d’accès, car les variables sont évaluées au moment de l’exécution (après le déclenchement du déclencheur).

Étiquettes

En plus de spécifier des balises dans les listes branches comme décrit dans la section précédente, vous pouvez directement spécifier des balises à inclure ou exclure :

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Si vous ne spécifiez aucun déclencheur de balise, par défaut, les balises ne déclenchent pas de pipelines.

Important

Si vous spécifiez des balises en combinaison avec des filtres de branche, le déclencheur se déclenche si le filtre de branche est satisfait ou si le filtre de balise est satisfait. Par exemple, si une balise d’envoi satisfait le filtre de branche, le pipeline se déclenche même si la balise est exclue par le filtre de balise, car l’envoi satisfait le filtre de branche.

Désactivation de l’intégration continue

Désactivation du déclencheur CI

Vous pouvez désactiver entièrement les déclencheurs CI en spécifiant trigger: none.

# A pipeline with no CI trigger
trigger: none

Important

Lorsque vous envoyez une modification à une branche, le fichier YAML dans cette branche est évalué pour déterminer si une exécution CI doit être démarrée.

Ignorer CI pour les poussées individuelles

Vous pouvez également indiquer à Azure Pipelines d’ignorer l’exécution d’un pipeline déclenchée normalement par une poussée. Il suffit d’inclure ***NO_CI*** dans le message d’un des commits qui font partie de la poussée, et Azure Pipelines ignore l’exécution CI pour cette poussée.

Vous pouvez également indiquer à Azure Pipelines d’ignorer l’exécution d’un pipeline déclenchée normalement par une poussée. Il suffit d’inclure [skip ci] dans le message ou la description de l’une des validations qui font partie d’un envoi, et Azure Pipelines ignorera l’exécution de CI pour cette envoi. Vous pouvez également utiliser une des variantes suivantes.

  • [skip ci] ou [ci skip]
  • skip-checks: true ou skip-checks:true
  • [skip azurepipelines] ou [azurepipelines skip]
  • [skip azpipelines] ou [azpipelines skip]
  • [skip azp] ou [azp skip]
  • ***NO_CI***

Utilisation du type de déclencheur dans les conditions

Il est courant d’exécuter différentes étapes ou phases et différents travaux dans votre pipeline en fonction du type de déclencheur qui a démarré l’exécution. Pour ce faire, utilisez la variable système Build.Reason. Par exemple, ajoutez la condition suivante à votre étape, tâche ou phase pour l’exclure des validations de demande de tirage.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Comportement des déclencheurs lors de la création de nouvelles branches

Il est courant de configurer plusieurs pipelines pour le même dépôt. Par exemple, vous pouvez avoir un pipeline pour générer les documents de votre application et un autre pour générer le code source. Vous pouvez configurer des déclencheurs CI avec des filtres de branche et des filtres de chemin appropriés dans chacun de ces pipelines. Par exemple, vous souhaiterez peut-être qu’un pipeline se déclenche lorsque vous envoyez une mise à jour au dossier docs, et un autre lorsque vous envoyez une mise à jour au code de votre application. Dans ce cas, vous devez comprendre comment les pipelines sont déclenchés lorsqu’une nouvelle branche est créée.

Voici le comportement lorsque vous envoyez une nouvelle branche (qui correspond aux filtres de branche) vers votre dépôt :

  • Si votre pipeline a des filtres de chemin d’accès, il est déclenché uniquement si la nouvelle branche a des modifications apportées aux fichiers qui correspondent à ce filtre de chemin d’accès.
  • Si votre pipeline n’a pas de filtres de chemin d’accès, il est déclenché même s’il n’y a aucune modification dans la nouvelle branche.

Caractères génériques

Lorsque vous spécifiez une branche, une étiquette ou un chemin d’accès, vous pouvez utiliser un nom exact ou un caractère générique. Les modèles de caractères génériques permettent à * de faire correspondre zéro ou plusieurs caractères, et à ? de faire correspondre un caractère unique.

  • Si vous commencez votre modèle avec * dans un pipeline YAML, vous devez encapsuler le modèle entre guillemets, comme "*-releases".
  • Pour les branches et les balises :
    • Un caractère générique peut apparaître n’importe où dans le modèle.
  • Pour les chemins d’accès :
    • Dans Azure DevOps Server 2022 et versions ultérieures, y compris Azure DevOps Services, un caractère générique peut apparaître n’importe où dans un modèle de chemin, et vous pouvez utiliser * ou ?.
    • Dans Azure DevOps Server 2020 et versions antérieures, vous pouvez inclure * comme caractère final, mais cela ne fait rien de différent de la spécification du nom de répertoire par lui-même. Vous ne pouvez pas inclure * au milieu d’un filtre de chemin d’accès, et vous ne pouvez pas utiliser ?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Déclencheurs PR

Les déclencheurs de demande de tirage (PR) entraînent l’exécution d’un pipeline chaque fois que vous ouvrez une demande de tirage ou que vous y poussez des changements. Dans Azure Repos Git, cette fonctionnalité est implémentée par des stratégies de branche. Pour activer la validation PR, accédez aux stratégies de branche de la branche souhaitée, puis configurez la Stratégie de validation de build pour cette branche. Pour plus d’informations, consultez Configurer des stratégies de branche.

Si vous avez une PR ouverte et que vous poussez des changements sur sa branche source, plusieurs pipelines peuvent s’exécuter :

  • Les pipelines spécifiés par la stratégie de validation de build de la branche cible s’exécutent sur le commit de fusion (le code fusionné entre les branches source et cible de la demande de tirage), qu’il existe ou non des commits poussés dont les messages ou descriptions contiennent [skip ci] (ou une de ses variantes).
  • Les pipelines déclenchés par les changements dans la branche source de la PR, s’il n’y a pas de commits poussés dont les messages ou descriptions contiennent [skip ci] (ou une de ses variantes). Si au moins un commit poussé contient [skip ci], les pipelines ne s’exécutent pas.

Enfin, une fois que vous avez fusionné la PR, Azure Pipelines exécute les pipelines CI déclenchés par des poussées sur la branche cible, même si les messages ou les descriptions des commits fusionnés contiennent [skip ci] (ou une de ses variantes).

Notes

Pour configurer des builds de validation pour un dépôt Git Azure Repos, vous devez être administrateur de son projet.

Notes

Les brouillons de demande de tirage ne déclenchent pas de pipeline même si vous configurez une stratégie de branche.

Valider les contributions des duplications

La génération de demandes de tirage à partir de duplications Azure Repos n’est pas différente de la génération de demandes de tirage au sein du même dépôt ou projet. Vous pouvez créer des duplications seulement dans l’organisation dont votre projet fait partie.

Limiter l’étendue d’autorisation du travail

Azure Pipelines fournit plusieurs paramètres de sécurité pour configurer l’étendue d’autorisation du travail dans laquelle vos pipelines s’exécutent.

Limiter l’étendue d’autorisation du travail au projet actuel

Azure Pipelines fournit deux paramètres Limiter l’étendue d’autorisation du travail au projet actuel :

  • Limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines hors mise en production : ce paramètre s’applique aux pipelines YAML et aux pipelines de build classiques. Il ne s’applique pas aux pipelines de mise en production classiques.
  • Limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines de mise en production : ce paramètre s’applique uniquement aux pipelines de mise en production classiques.

Les pipelines s’exécutent avec des jetons d’accès étendus à la collection, sauf si le paramètre approprié pour le type de pipeline est activé. Les paramètres Limiter l’étendue d’autorisation du travail vous permettent de réduire l’étendue d’accès de tous les pipelines au projet actuel. Cela peut impacter votre pipeline si vous accédez à un dépôt Git Azure Repos dans un autre projet de votre organisation.

Si votre dépôt Git Azure Repos est dans un projet différent de celui de votre pipeline et que le paramètre Limiter l’étendue d’autorisation du travail pour votre type de pipeline est activé, vous devez accorder l’autorisation à l’identité de service de build pour votre pipeline sur le deuxième projet. Pour plus d’informations, consultez Gérer les autorisations de compte de service de build.

Azure Pipelines fournit un paramètre de sécurité pour configurer l’étendue d’autorisation du travail dans laquelle vos pipelines s’exécutent.

  • Limiter l’étendue d’autorisation du travail au projet actuel : ce paramètre s’applique aux pipelines YAML et aux pipelines de build classiques. Il ne s’applique pas aux pipelines de mise en production classiques.

Les pipelines s’exécutent avec des jetons d’accès étendus à la collection, sauf si l’option Limiter l’étendue d’autorisation du travail au projet actuel est activée. Ce paramètre vous permet de réduire l’étendue d’accès de tous les pipelines au projet actuel. Cela peut impacter votre pipeline si vous accédez à un dépôt Git Azure Repos dans un autre projet de votre organisation.

Si votre dépôt Git Azure Repos est dans un projet différent de celui de votre pipeline et que le paramètre Limiter l’étendue d’autorisation du travail est activé, vous devez accorder l’autorisation à l’identité de service de build pour votre pipeline sur le deuxième projet. Pour plus d’informations, consultez Étendue d’autorisation de travail.

Pour plus d’informations sur Limiter l’étendue d’autorisation du travail, consultez Comprendre les jetons d’accès du travail.

Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés

Les pipelines peuvent accéder à n’importe quel dépôt Azure DevOps dans les projets autorisés, comme décrit dans la section précédente Limiter l’étendue d’autorisation du travail au projet actuel, sauf si l’option Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activée. Quand cette option est activée, vous pouvez réduire l’étendue d’accès de tous les pipelines aux seuls dépôts Azure DevOps explicitement référencés par une étape checkout ou une instruction uses dans le travail de pipeline qui utilise ce dépôt.

Pour configurer ce paramètre, accédez à Pipelines, Paramètres dans Paramètres de l’organisation ou Paramètres du projet. S’il est activé au niveau de l’organisation, le paramètre est grisé et indisponible dans les paramètres du projet.

Quand Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activé, vos pipelines YAML doivent explicitement référencer tous les dépôts Git Azure Repos que vous voulez utiliser dans le pipeline comme étape d’extraction dans le travail qui utilise le dépôt. Vous ne pouvez pas récupérer le code avec des tâches de script et des commandes git pour un dépôt Git Azure Repos, sauf si ce dépôt est d’abord référencé explicitement.

Dans certains cas, vous n’avez pas besoin de référencer explicitement un dépôt Git Azure Repos avant de l’utiliser dans votre pipeline quand Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activé.

  • Si vous n’avez pas d’étape d’extraction explicite dans votre pipeline, c’est comme si vous aviez une étape checkout: self et que le dépôt self était extrait.
  • Si vous utilisez un script pour effectuer des opérations en lecture seule sur un dépôt dans un projet public, vous n’avez pas besoin de référencer le dépôt du projet public dans une étape checkout.
  • Si vous utilisez un script qui fournit sa propre authentification au dépôt, par exemple, un jeton PAT, vous n’avez pas besoin de référencer ce dépôt dans une étape checkout.

Par exemple, quand Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activé, si votre pipeline est dans le dépôt FabrikamProject/Fabrikam de votre organisation et que vous voulez utiliser un script pour extraire le dépôt FabrikamProject/FabrikamTools, vous devez référencer ce dépôt dans une étape checkout ou avec une instruction uses.

Si vous extrayez déjà le dépôt FabrikamTools dans votre pipeline avec une étape d’extraction, vous pouvez ensuite utiliser des scripts pour interagir avec ce dépôt.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Notes

Dans de nombreux scénarios, l’extraction multidépôt peut être utilisée, pour ne pas avoir à utiliser des scripts pour extraire des dépôts supplémentaires dans votre pipeline. Pour plus d’informations, consultez Extraire plusieurs dépôts dans votre pipeline.

Protéger l’accès aux dépôts dans les pipelines YAML

Les pipelines peuvent accéder à n’importe quel dépôt Azure DevOps dans les projets autorisés, comme décrit dans la section précédente Limiter l’étendue d’autorisation du travail au projet actuel, sauf si Protéger l’accès aux dépôts dans les pipelines YAML est activé. Quand cette option est activée, vous pouvez réduire l’étendue d’accès de tous les pipelines aux seuls dépôts Azure DevOps explicitement référencés par une étape checkout ou une instruction uses dans le travail de pipeline qui utilise ce dépôt.

Pour configurer ce paramètre, accédez à Pipelines, Paramètres dans Paramètres de l’organisation ou Paramètres du projet. S’il est activé au niveau de l’organisation, le paramètre est grisé et indisponible dans les paramètres du projet.

Important

Protéger l’accès aux dépôts dans les pipelines YAML est activé par défaut pour les nouvelles organisations et les projets créés après mai 2020. Quand Protéger l’accès aux dépôts dans les pipelines YAML est activé, vos pipelines YAML doivent explicitement référencer tous les dépôts Git Azure Repos que vous voulez utiliser dans le pipeline comme une étape d’extraction dans le travail qui utilise le dépôt. Vous ne pouvez pas récupérer le code avec des tâches de script et des commandes git pour un dépôt Git Azure Repos, sauf si ce dépôt est d’abord référencé explicitement.

Dans certains cas, vous n’avez pas besoin de référencer explicitement un dépôt Git Azure Repos avant de l’utiliser dans votre pipeline si Protéger l’accès aux dépôts dans les pipelines YAML est activé.

  • Si vous n’avez pas d’étape d’extraction explicite dans votre pipeline, c’est comme si vous aviez une étape checkout: self et que le dépôt self était extrait.
  • Si vous utilisez un script pour effectuer des opérations en lecture seule sur un dépôt dans un projet public, vous n’avez pas besoin de référencer le dépôt du projet public dans une étape checkout.
  • Si vous utilisez un script qui fournit sa propre authentification au dépôt, par exemple, un jeton PAT, vous n’avez pas besoin de référencer ce dépôt dans une étape checkout.

Par exemple, quand Protéger l’accès aux dépôts dans les pipelines YAML est activé, si votre pipeline est dans le dépôt FabrikamProject/Fabrikam de votre organisation et que vous voulez utiliser un script pour extraire le dépôt FabrikamProject/FabrikamTools, vous devez référencer ce dépôt dans une étape checkout ou avec une instruction uses.

Si vous extrayez déjà le dépôt FabrikamTools dans votre pipeline avec une étape d’extraction, vous pouvez ensuite utiliser des scripts pour interagir avec ce dépôt.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Notes

Dans de nombreux scénarios, l’extraction multidépôt peut être utilisée, pour ne pas avoir à utiliser des scripts pour extraire des dépôts supplémentaires dans votre pipeline. Pour plus d’informations, consultez Extraire plusieurs dépôts dans votre pipeline.

Checkout

Lorsqu’un pipeline est déclenché, Azure Pipelines extrait votre code source à partir du référentiel Git Azure Repos. Vous pouvez contrôler différents aspects de la façon dont cela se produit.

Notes

Lorsque vous incluez une étape d’extraction dans votre pipeline, nous exécutons la commande suivante : git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Si cela ne répond pas à vos besoins, vous pouvez choisir d’exclure la validation intégrée par checkout: none, puis d’utiliser une tâche de script pour effectuer votre propre validation.

Version préférée de Git

L’agent Windows est fourni avec sa propre copie de Git. Si vous préférez fournir votre propre Git plutôt que d’utiliser la copie incluse, définissez System.PreferGitFromPath sur true. Ce paramètre a toujours la valeur true sur les agents non Windows.

Chemin de l’extraction

Si vous extrayez un seul référentiel , par défaut, votre code source est extrait dans un répertoire appelé s. Pour les pipelines YAML, vous pouvez modifier ce paramètre en spécifiant checkout avec path. Le chemin spécifié est relatif à $(Agent.BuildDirectory). Par exemple : si la valeur du chemin d’extraction est mycustompath, et que $(Agent.BuildDirectory) est C:\agent\_work\1, le code source est extrait dans C:\agent\_work\1\mycustompath.

Si vous utilisez plusieurs étapes checkout et que vous extrayez plusieurs dépôts, sans spécifier explicitement le dossier à l’aide de path, chaque dépôt est placé dans un sous-dossier nommé s d’après le dépôt. Par exemple, si vous extrayez deux référentiels nommés tools et code, le code source est extrait dans C:\agent\_work\1\s\tools et C:\agent\_work\1\s\code.

Notez que la valeur du chemin d’extraction ne peut pas être définie pour atteindre les niveaux de répertoire au-dessus de $(Agent.BuildDirectory), path\..\anotherpath engendre donc un chemin d’extraction valide (C:\agent\_work\1\anotherpath), mais une valeur comme ..\invalidpath non (C:\agent\_work\invalidpath).

Vous pouvez configurer le paramètre path à l’étape de validation de votre pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Sous-modules

Vous pouvez configurer le paramètre submodules à l’étape de validation de votre pipeline si vous souhaitez télécharger des fichiers à partir de sous-modules.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Le pipeline de build vérifie vos sous-modules Git tant qu’ils sont :

  • Non authentifié : Dépôt public non authentifié sans informations d’identification requises pour le clonage ou l’extraction.

  • Authentifié :

    • Contenu dans le même projet que le référentiel Git Azure Repos spécifié ci-dessus. Les mêmes informations d’identification utilisées par l’agent pour obtenir les sources du référentiel principal sont également utilisées pour obtenir les sources des sous-modules.

    • Ajouté à l’aide d’une URL relative au référentiel principal. Par exemple

      • Celui-ci serait extrait : git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        Dans cet exemple, le sous-module fait référence à un référentiel (FabrikamFiber) dans la même organisation Azure DevOps, mais dans un autre projet (FabrikamFiberProject). Les mêmes informations d’identification utilisées par l’agent pour obtenir les sources du référentiel principal sont également utilisées pour obtenir les sources des sous-modules. Cela nécessite que le jeton d’accès au travail ait accès au référentiel dans le deuxième projet. Si vous avez restreint le jeton d’accès au travail comme expliqué dans la section ci-dessus, vous ne pourrez pas le faire. Vous pouvez autoriser le jeton d’accès au travail à accéder au référentiel dans le deuxième projet (a) en accordant explicitement l’accès au compte de service de build de projet dans le deuxième projet ou (b) à l’aide de jetons d’accès étendus à la collection au lieu de jetons étendus au projet pour l’ensemble de l’organisation. Pour plus d’informations sur ces options et leurs implications en matière de sécurité, consultez Accéder aux référentiels, artefacts et autres ressources.

      • Celui-ci ne serait pas extrait : git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternative à l’utilisation de l’option Extraire les sous-modules

Dans certains cas, vous ne pouvez pas utiliser l’option Extraire les sous-modules. Vous pouvez avoir un scénario dans lequel un autre ensemble d’informations d’identification est nécessaire pour accéder aux sous-modules. Cela peut se produire, par exemple, si votre référentiel principal et vos référentiels de sous-module ne sont pas stockés dans la même organisation Azure DevOps, ou si votre jeton d’accès au travail n’a pas accès au référentiel dans un autre projet.

Si vous ne pouvez pas utiliser l’option Extraire les sous-modules, vous pouvez utiliser une étape de script personnalisée pour extraire les sous-modules. Tout d’abord, obtenez un jeton d’accès personnel (PAT) et préfixez-le avec pat:. Ensuite, encodez cette chaîne préfixée en base64 pour créer un jeton d’authentification de base. Enfin, ajoutez ce script à votre pipeline :

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Veillez à remplacer « <BASE64_ENCODED_STRING> » par votre chaîne « pat:token » encodée en Base64.

Utilisez une variable secrète dans votre projet ou pipeline de build pour stocker le jeton d’authentification de base que vous avez généré. Utilisez cette variable pour remplir le secret dans la commande Git ci-dessus.

Remarque

Q : Pourquoi ne puis-je pas utiliser un gestionnaire d’informations d’identification Git sur l’agent ? R : Stocker les informations d’identification du sous-module dans un gestionnaire d’informations d’identification Git installé sur votre agent de build privé n’est généralement pas efficace, car le gestionnaire d’identification peut vous demander de ressaisir les informations d’identification chaque fois que le sous-module est mis à jour. Cela n’est pas souhaitable pendant les builds automatisés lorsque l’interaction utilisateur n’est pas possible.

Synchroniser les balises

Important

La fonctionnalité de synchronisation des balises est prise en charge dans Azure Repos Git avec Azure DevOps Server 2022.1 et versions ultérieures.

L’étape de validation utilise l’option --tags lors de l’extraction du contenu d’un référentiel Git. Cela entraîne l’extraction par le serveur de toutes les balises ainsi que de tous les objets pointés par ces balises. Cela augmente le temps d’exécution de la tâche dans un pipeline, en particulier si vous avez un grand référentiel avec plusieurs balises. En outre, l’étape d’extraction synchronise les balises même lorsque vous activez l’option d’extraction superficielle, ce qui peut être contraire à son objectif. Pour réduire la quantité de données récupérées ou extraites d’un référentiel Git, Microsoft a ajouté une nouvelle option pour valider le contrôle du comportement des balises de synchronisation. Cette option est disponible à la fois dans les pipelines classiques et YAML.

La synchronisation des balises lors de l’extraction d’un référentiel peut être configurée dans YAML en définissant la propriété fetchTags et dans l’interface utilisateur en configurant le paramètre Balises de synchronisation.

Vous pouvez configurer le paramètre fetchTags à l’étape Extraction de votre pipeline.

Pour configurer le paramètre dans YAML, définissez la propriété fetchTags.

steps:
- checkout: self
  fetchTags: true

Vous pouvez également configurer ce paramètre à l’aide de l’option Balises de synchronisation dans l’interface utilisateur des paramètres de pipeline.

  1. Modifiez votre pipeline YAML et choisissez Plus d’actions, Déclencheurs.

    Capture d’écran du menu Plus de déclencheurs.

  2. Choisissez YAML, Obtenir des sources.

    Capture d’écran de Sources get.

  3. Configurez le paramètre Balises de synchronisation.

    Capture d’écran du paramètre Balises de synchronisation.

Notes

Si vous définissez fetchTags explicitement dans votre étape checkout, ce paramètre prend la priorité sur le paramètre configuré dans l’interface utilisateur des paramètres de pipeline.

Comportement par défaut

  • Pour les pipelines existants créés avant la publication d’Azure DevOps sprint 209, publiés en septembre 2022, la valeur par défaut pour la synchronisation des balises reste identique au comportement existant avant l’ajout des options Balises de synchronisation, à savoir true.
  • Pour les nouveaux pipelines créés après la version sprint d’Azure DevOps 209, la valeur par défaut pour la synchronisation des balises est false.

Notes

Si vous définissez fetchTags explicitement dans votre étape checkout, ce paramètre prend la priorité sur le paramètre configuré dans l’interface utilisateur des paramètres de pipeline.

Récupération (fetch) superficielle

Vous souhaitez peut-être limiter le nombre de téléchargements dans l’historique. Cela aboutit effectivement à git fetch --depth=n. Si votre dépôt est volumineux, cette option peut rendre votre pipeline de build plus efficace. Votre dépôt peut être volumineux s’il est utilisé depuis longtemps et s’il a un historique important. Il peut également être volumineux si vous avez ajouté et supprimé ultérieurement des fichiers volumineux.

Important

Les nouveaux pipelines créés après la mise à jour de septembre 2022 d’Azure DevOps sprint 209 ont une extraction superficielle activée par défaut et configurée avec une profondeur de 1. Auparavant, la valeur par défaut était de ne pas extraire de manière superficielle. Pour vérifier votre pipeline, affichez le paramètre Extraction superficielle dans l’interface utilisateur des paramètres de pipeline, comme décrit dans la section suivante.

Vous pouvez configurer le paramètre fetchDepth à l’étape Extraction de votre pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Vous pouvez également configurer la profondeur d’extraction en définissant l’option Profondeur superficielle dans l’interface utilisateur des paramètres du pipeline.

  1. Modifiez votre pipeline YAML et choisissez Plus d’actions, Déclencheurs.

    Capture d’écran du menu Plus de déclencheurs.

  2. Choisissez YAML, Obtenir des sources.

    Capture d’écran de Sources get.

  3. Configurez le paramètre Extraction superficielle. Décochez Extraction superficielle pour désactiver l’extraction superficielle, ou cochez la case et entrez une profondeur pour activer l’extraction superficielle.

    Capture d’écran des options.

Notes

Si vous définissez fetchDepth explicitement dans votre étape checkout, ce paramètre prend la priorité sur le paramètre configuré dans l’interface utilisateur des paramètres de pipeline. La définition fetchDepth: 0 récupère tous les historiques et remplace le paramètre Extraction superficielle.

Dans ce cas, cette option peut vous aider à conserver les ressources réseau et de stockage. Cela peut également vous faire gagner du temps. La raison pour laquelle cela n’économise pas toujours du temps est que, dans certaines situations, le serveur peut avoir besoin de passer du temps à calculer les validations à télécharger pour la profondeur que vous spécifiez.

Notes

Lorsque le pipeline est démarré, la branche à générer est résolue en ID de validation. Ensuite, l’agent récupère la branche et extrait la validation souhaitée. Il existe une petite fenêtre entre le moment où une branche est résolue en ID de validation et le moment où l’agent effectue l’extraction. Si la branche est mise à jour rapidement et que vous définissez une valeur très petite pour l’extraction superficielle, la validation peut ne pas exister lorsque l’agent tente de l’extraire. Si cela se produit, augmentez le paramètre de profondeur d’extraction superficielle.

Ne pas synchroniser les sources

Vous souhaiterez peut-être ignorer l’extraction de nouvelles validations. Cette option peut être utile dans les cas où vous souhaitez :

  • Utiliser Git init, config et fetch à l’aide de vos propres options personnalisées.

  • Utiliser un pipeline de build pour exécuter simplement un travail d’automatisation (par exemple, certains scripts) qui ne dépend pas du code dans le contrôle de version.

Vous pouvez configurer le paramètre Ne pas synchroniser les sources à l’étape Extraction de votre pipeline, en définissant checkout: none.

steps:
- checkout: none  # Don't sync sources

Notes

Lorsque vous utilisez cette option, l’agent ignore également l’exécution des commandes Git qui nettoient le référentiel.

Nettoyer le build

Vous pouvez effectuer différentes formes de nettoyage du répertoire de travail de votre agent autohébergé avant l’exécution d’un build.

En général, pour des performances plus rapides de vos agents auto-hébergés, ne nettoyez pas le dépôt. Dans ce cas, pour obtenir les meilleures performances, assurez-vous que vous générez également de manière incrémentielle en désactivant toute option Nettoyer de la tâche ou de l’outil que vous utilisez pour générer.

Si vous avez besoin de nettoyer le dépôt (par exemple, pour éviter les problèmes causés par les fichiers résiduels d’une build précédente), vos options sont présentées ci-dessous.

Notes

Le nettoyage n’est pas efficace si vous utilisez un agent hébergé par Microsoft, car vous obtiendrez un nouvel agent à chaque fois.

Vous pouvez configurer le paramètre clean à l’étape Extraction de votre pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Quand clean est défini sur true, le pipeline de build effectue une annulation des modifications apportées dans $(Build.SourcesDirectory). Plus précisément, les commandes Git suivantes sont exécutées avant d’extraire la source.

git clean -ffdx
git reset --hard HEAD

Pour plus d’options, vous pouvez configurer le paramètre workspace d’un travail.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Cela donne les options de nettoyage suivantes.

  • outputs : même opération que le paramètre de nettoyage décrit dans la tâche de validation précédente, plus : Supprime et recrée $(Build.BinariesDirectory). Notez que $(Build.ArtifactStagingDirectory) et $(Common.TestResultsDirectory) sont toujours supprimés et recréés avant chaque build, peu importe leur valeur.

  • resources : supprime et recrée $(Build.SourcesDirectory). Cela entraîne l’initialisation d’un nouveau référentiel Git local pour chaque build.

  • all : supprime et recrée $(Agent.BuildDirectory). Cela entraîne l’initialisation d’un nouveau référentiel Git local pour chaque build.

Étiqueter les sources

Vous pouvez étiqueter vos fichiers de code source pour permettre à votre équipe d’identifier facilement la version de chaque fichier incluse dans la build terminée. Vous avez également la possibilité de spécifier si le code source doit être étiqueté pour tous les builds ou uniquement pour les builds réussis.

Vous ne pouvez actuellement pas configurer ce paramètre dans YAML, mais vous pouvez dans l’éditeur classique. Lors de la modification d’un pipeline YAML, vous pouvez accéder à l’éditeur classique en choisissant n’importe quel déclencheur dans le menu de l’éditeur YAML.

Configurez les options Git, YAML.

Dans l’éditeur classique, choisissez YAML, choisissez la tâche Sources get, puis configurez les propriétés souhaitées.

Dans l’éditeur Classique, choisissez YAML et Sources get.

Dans Format de balise, vous pouvez utiliser des variables définies par l’utilisateur et prédéfinies qui ont une étendue de « Tout ». Par exemple :

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

Les quatre premières variables sont prédéfinies. Vous pouvez définir My.Variable sous l’onglet Variables.

Le pipeline de build étiquette vos sources avec une étiquette Git.

Certaines variables de build peuvent produire une valeur qui n’est pas une étiquette valide. Par exemple, des variables comme $(Build.RequestedFor) et $(Build.DefinitionName) peuvent contenir des espaces blancs. Si la valeur contient des espaces blancs, l’étiquette n’est pas créée.

Une fois que les sources sont étiquetées par votre pipeline de build, un artefact avec la référence Git refs/tags/{tag} est automatiquement ajouté à la build terminée. Cela offre à votre équipe une traçabilité supplémentaire et un moyen plus convivial de naviguer de la build vers le code qui a été généré. L’étiquette est considérée comme un artefact de build, car elle est produite par la build. Quand la build est supprimée manuellement ou par une stratégie de conservation, l’étiquette est également supprimée.

Questions fréquentes (FAQ)

Les problèmes liés à l’intégration d’Azure Repos se répartissent en trois catégories :

  • Échec des déclencheurs : mon pipeline n’est pas déclenché quand je pousse une mise à jour dans le dépôt.
  • Échec de la validation : mon pipeline est déclenché, mais il échoue à l’étape de validation.
  • Version incorrecte : mon pipeline s’exécute, mais il utilise une version inattendue de la source/YAML.

Déclencheurs défaillants

Je viens de créer un pipeline YAML avec des déclencheurs CI/PR, mais le pipeline n’est pas déclenché.

Suivez chacune de ces étapes pour résoudre les problèmes liés à vos déclencheurs défaillants :

  • Vos déclencheurs CI ou PR YAML sont-ils remplacés par des paramètres de pipeline dans l’interface utilisateur ? Lors de la modification de votre pipeline, choisissez ... puis Déclencheurs.

    Interface utilisateur de paramètres du pipeline.

    Vérifiez le paramètre Remplacer le déclencheur YAML ici pour les types de déclencheurs (intégration continue ou validation de demande de tirage) disponibles pour votre dépôt.

    Remplacer le déclencheur YAML à partir d’ici.

  • Configurez-vous le déclencheur de demande de tirage dans le fichier YAML ou dans des stratégies de branche pour le dépôt ? Pour un dépôt Git Azure Repos, vous ne pouvez pas configurer de déclencheur PR dans le fichier YAML. Vous devez utiliser des stratégies de branche.

  • Votre pipeline est-il en pause ou désactivé ? Ouvrez l’éditeur du pipeline, puis sélectionnez Paramètres pour vérifier. Si votre pipeline est suspendu ou désactivé, les déclencheurs ne fonctionnent pas.

  • Avez-vous mis à jour le fichier YAML dans la branche appropriée ? Si vous envoyez une mise à jour vers une branche, le fichier YAML de cette même branche régit le comportement d’intégration continue. Si vous envoyez une mise à jour vers une branche source, le fichier YAML résultant de la fusion de la branche source avec la branche cible régit le comportement de la demande de tirage. Assurez-vous que le fichier YAML dans la branche appropriée a la configuration CI ou PR nécessaire.

  • Avez-vous correctement configuré le déclencheur ? Lorsque vous définissez un déclencheur YAML, vous pouvez spécifier des clauses include et exclude pour les branches, les étiquettes et les chemins d’accès. Vérifiez que la clause include correspond aux détails de votre validation et que la clause exclude ne les exclut pas. Vérifiez la syntaxe des déclencheurs et assurez-vous qu’elle est exacte.

  • Avez-vous utilisé des variables pour définir le déclencheur ou les chemins d’accès ? Cela n’est pas pris en charge.

  • Avez-vous utilisé des modèles pour votre fichier YAML ? Dans ce cas, assurez-vous que vos déclencheurs sont définis dans le fichier YAML principal. Les déclencheurs définis dans les fichiers de modèle ne sont pas pris en charge.

  • Avez-vous exclu les branches ou chemins vers lesquels vous avez envoyé vos modifications ? Testez en envoyant une modification vers un chemin inclus dans une branche incluse. Notez que les chemins d’accès dans les déclencheurs respectent la casse. Veillez à utiliser la même casse que pour les dossiers réels lors de la spécification des chemins d’accès dans les déclencheurs.

  • Venez-vous d’envoyer une nouvelle branche ? Dans ce cas, la nouvelle branche peut ne pas démarrer une nouvelle exécution. Consultez la section « Comportement des déclencheurs lors de la création de nouvelles branches ».

Mes déclencheurs CI ou PR fonctionnent bien. Mais ils ont cessé de travailler maintenant.

Passez d’abord en revue les étapes de résolution des problèmes de la question précédente. Ensuite, procédez comme suit :

  • Avez-vous des conflits de fusion dans votre demande de tirage ? Pour une demande de tirage qui n’a pas déclenché de pipeline, ouvrez-la et vérifiez si elle a un conflit de fusion. Résoudre le conflit de fusion.

  • Rencontrez-vous un retard dans le traitement des événements d’envoi ou de demande de tirage ? Vous pouvez généralement vérifier cela en regardant si le problème est spécifique à un pipeline unique ou est commun à tous les pipelines ou dépôts de votre projet. Si une mise à jour d’envoi ou de demande de tirage dans l’un des dépôts présente ce symptôme, nous pouvons rencontrer des retards dans le traitement des événements de mise à jour. Vérifiez si nous rencontrons une panne de service sur notre page d’état. Si la page d’état affiche un problème, notre équipe a probablement déjà commencé à travailler dessus. Consultez fréquemment la page pour obtenir des mises à jour sur le problème.

Je ne souhaite pas que les utilisateurs remplacent la liste des branches pour les déclencheurs lorsqu’ils mettent à jour le fichier YAML. Comment procéder ?

Les utilisateurs disposant des autorisations nécessaires pour contribuer au code peuvent mettre à jour le fichier YAML et inclure/exclure des branches supplémentaires. Par conséquent, les utilisateurs peuvent inclure leur propre fonctionnalité ou branche utilisateur dans leur fichier YAML et envoyer cette mise à jour vers une branche de fonctionnalité ou utilisateur. Cela peut entraîner le déclenchement du pipeline pour toutes les mises à jour de cette branche. Si vous souhaitez empêcher ce comportement, vous pouvez :

  1. Modifier le pipeline dans l’interface utilisateur Azure Pipelines.
  2. Accédez au menu Déclencheurs.
  3. Sélectionnez Remplacer le déclencheur d’intégration continue YAML à partir d’ici.
  4. Spécifiez les branches à inclure ou à exclure pour le déclencheur.

Quand vous suivez ces étapes, tous les déclencheurs CI spécifiés dans le fichier YAML sont ignorés.

J’ai de multiples référentiels dans mon pipeline YAML. Comment configurer des déclencheurs pour chaque référentiel ?

Consultez les déclencheurs dans Utilisation de multiples référentiels.

Échec de l’extraction

L’erreur suivante s’affiche dans le fichier journal lors de l’étape de validation. Comment la corriger ?

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

Suivez chacune de ces étapes pour résoudre l’échec d’extraction :

  • Le dépôt existe-t-il toujours ? Tout d’abord, vérifiez en l’ouvrant dans la page Repos.

  • Accédez-vous au dépôt avec un script ? Si c’est le cas, vérifiez le paramètre Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés. Si Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activé, vous ne pouvez pas extraire les dépôts Git Azure Repos avec un script, sauf s’ils sont d’abord référencés explicitement dans le pipeline.

  • Quelle est l’étendue d’autorisation du travail du pipeline ?

    • Si l’étendue est collection :

      • Il peut s’agir d’une erreur intermittente. Réexécutez le pipeline.
      • Quelqu’un a peut-être supprimé l’accès au compte de service de build de la collection de projets.
        • Accédez à Paramètres du projet pour le projet où se trouve le dépôt. Sélectionnez Repos > Dépôts > dépôt spécifique, puis Sécurité.
        • Vérifiez si Service de build de la collection de projets (nom de votre collection) existe dans la liste des utilisateurs.
        • Vérifiez si ce compte a l’accès Créer une étiquette et Lire.

    • Si l’étendue est projet :

      • Le dépôt se trouve-t-il dans le même projet que le pipeline ?
        • Oui :
          • Il peut s’agir d’une erreur intermittente. Réexécutez le pipeline.
          • Quelqu’un a peut-être supprimé l’accès au compte de service de build de projet.
            • Accédez à Paramètres du projet pour le projet où se trouve le dépôt. Sélectionnez Repos > Dépôts > dépôt spécifique, puis Sécurité.
            • Vérifiez si Service de build de nom-de-votre-projet (nom de votre collection) existe dans la liste des utilisateurs.
            • Vérifiez si ce compte a l’accès Créer une étiquette et Lire.
        • Non :

Version incorrecte

Une version incorrecte du fichier YAML est utilisée dans le pipeline. Pourquoi ?

  • Pour les déclencheurs CI, le fichier YAML qui se trouve dans la branche que vous envoyez est évalué pour voir si une build CI doit être exécutée.
  • Pour les déclencheurs PR, le fichier YAML résultant de la fusion des branches source et cible de la PR est évalué pour voir si une build PR doit être exécutée.