Créer des dépôts Bitbucket Cloud

  • Article

Azure DevOps Services

Azure Pipelines peut automatiquement générer et valider chaque demande de tirage, et les valider dans votre dépôt Bitbucket Cloud. Cet article explique comment configurer l’intégration entre Bitbucket Cloud et Azure Pipelines.

Bitbucket et Azure Pipelines sont deux services indépendants qui s’intègrent bien ensemble. Vos utilisateurs Bitbucket Cloud n’ont pas automatiquement accès à Azure Pipelines. Vous devez les ajouter explicitement à Azure Pipelines.

Accès aux référentiels Bitbucket

Vous créez un pipeline en sélectionnant d’abord un dépôt Bitbucket Cloud, 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 être autorisé à accéder à vos dépôts pour extraire le code pendant les builds. En outre, l’utilisateur qui configure le pipeline doit disposer d’un accès administrateur à Bitbucket, car cette identité est utilisée pour inscrire un webhook dans Bitbucket.

Il existe 2 types d’authentification pour accorder à Azure Pipelines l’accès à vos dépôts Bitbucket Cloud lors de la création d’un pipeline.

Type d'authentification Exécution de pipelines avec
1. OAuth Votre identité Bitbucket personnelle
2. Nom d’utilisateur et mot de passe Votre identité Bitbucket personnelle

Authentification OAuth

OAuth est le type d’authentification le plus simple à utiliser pour les dépôts dans votre compte Bitbucket. Les mises à jour d’état de Bitbucket sont effectuées au nom de votre identité Bitbucket personnelle. Pour que les pipelines continuent de fonctionner, l’accès à votre dépôt doit rester actif.

Pour utiliser OAuth, connectez-vous à Bitbucket lorsque vous y êtes invité lors de la création du pipeline. Cliquez ensuite sur Autoriser pour autoriser avec OAuth. Une connexion OAuth sera enregistrée dans votre projet Azure DevOps pour une utilisation ultérieure, ainsi que dans le pipeline en cours de création.

Notes

Le nombre maximal de dépôts Bitbucket que l’interface utilisateur Azure DevOps Services peut charger est de 2 000.

Authentification par mot de passe

Les builds et les mises à jour d’état de Bitbucket sont effectuées pour le compte de votre identité personnelle. Pour que les builds continuent de fonctionner, l’accès à votre dépôt doit rester actif.

Pour créer une connexion par mot de passe, consultez Connexions de service dans les paramètres de votre projet Azure DevOps. Créez une connexion de service Bitbucket et fournissez le nom d’utilisateur et le mot de passe pour vous connecter à votre dépôt Bitbucket Cloud.

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

Notes

Pour les dépôts Bitbucket Cloud, l’utilisation de la syntaxe branches est la seule façon de spécifier des déclencheurs d’étiquette. La syntaxe tags: n’est pas prise en charge pour Bitbucket.

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 l’intégration continue pour les validations individuelles

Vous pouvez également indiquer à Azure Pipelines d’ignorer l’exécution d’un pipeline qu’un envoi déclencherait normalement. 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) causent l’exécution chaque fois qu’une demande de tirage est ouverte avec l’une des branches cibles spécifiées ou quand des mises à jour sont faites sur ce type de demande de tirage.

Branches

Vous pouvez spécifier les branches cibles quand vous validez vos demandes de tirage. Par exemple, pour valider les demandes de tirage qui ciblent master et releases/*, vous pouvez utiliser le déclencheur pr suivant.

pr:
- main
- releases/*

Cette configuration démarre une nouvelle exécution la première fois qu’une nouvelle demande de tirage est créée et après chaque mise à jour apportée à la demande de tirage.

Vous pouvez spécifier le nom complet de la branche (par exemple, master) ou un caractère générique (par exemple, releases/*).

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.

Chaque nouvelle exécution génère la dernière validation à partir de la branche source de la demande de tirage. Cela diffère de la façon dont Azure Pipelines génère les demandes de tirage dans d’autres dépôts (par exemple, Azure Repos ou GitHub), où il génère la validation de fusion. Malheureusement, Bitbucket n’expose pas d’informations sur la validation de fusion, qui contient le code fusionné entre les branches source et cible de la demande de tirage.

Si aucun déclencheur pr n’apparaît dans votre fichier YAML, les validations de demande de tirage sont automatiquement activées pour toutes les branches, comme si vous aviez écrit le déclencheur pr suivant. Cette configuration déclenche une build lors de la création d’une demande de tirage et lorsque les validations entrent dans la branche source d’une demande de tirage active.

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

Important

Lorsque vous spécifiez un déclencheur pr, il remplace le déclencheur implicite prpar défaut, et seuls les envois aux branches explicitement configurées pour être incluses déclenchent un pipeline.

Pour les déclencheurs plus complexes qui doivent exclure certaines branches, vous devez utiliser la syntaxe complète, comme indiqué dans l’exemple suivant.

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

Chemins

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

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

Conseils :

  • Les caractères génériques ne sont pas pris en charge avec les 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).

Mises à jour de demande de tirage multiples

Vous pouvez spécifier si les mises à jour supplémentaires d’une demande de tirage doivent annuler les exécutions de validation en cours pour la même demande de tirage. Par défaut, il s’agit de true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Désactivation de la validation des demandes de tirage

Vous pouvez désactiver entièrement la validation des demandes de tirage en spécifiant pr: none.

# no PR triggers
pr: none

Pour plus d’informations, consultez Déclencheur de demande de tirage dans le schéma YAML.

Notes

Si votre déclencheur pr n’est pas déclenché, vérifiez que vous n’avez pas substitué les déclencheurs PR YAML dans l’interface utilisateur.

Exécutions informatives

Une exécution d’information vous indique qu’Azure DevOps n’a pas pu récupérer le code source d’un pipeline YAML. La récupération du code source se produit en réponse à des événements externes, par exemple, une validation d’envoi (push). Elle se produit également en réponse à des déclencheurs internes, par exemple, pour vérifier s’il existe des modifications de code et démarrer une exécution planifiée ou non. La récupération du code source peut échouer pour plusieurs raisons, notamment la limitation de requêtes par le fournisseur de référentiel Git. L’existence d’une exécution d’informations ne signifie pas nécessairement qu’Azure DevOps allait exécuter le pipeline.

Une exécution d’informations se présente comme dans la capture d’écran suivante.

Screenshot of an informational pipeline run.

Vous pouvez reconnaître une exécution d’informations par les attributs suivants :

  • L’état est Canceled
  • La durée est de < 1s
  • Le nom d’exécution contient l’un des textes suivants :
    • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
    • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
    • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
    • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
  • Le nom d’exécution contient généralement l’erreur BitBucket /GitHub qui a provoqué l’échec de la charge du pipeline YAML
  • Pas de phases/travaux/phases

En savoir plus sur les exécutions informationnelles.

Limites

Azure Pipelines charge au maximum 2 000 branches à partir d’un référentiel dans des listes déroulantes du portail Azure Devops, par exemple dans le paramètre branche par défaut des builds manuelles et planifiées, ou lorsque vous choisissez une branche lors de l’exécution manuelle d’un pipeline. Si vous ne voyez pas votre branche souhaitée dans la liste, tapez son nom manuellement.

FAQ

Les problèmes liés à l’intégration de Bitbucket appartiennent aux catégories suivantes :

  • Déclencheurs défaillants : Mon pipeline n’est pas déclenché lorsque j’envoie une mise à jour au dépôt.
  • 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.

    Pipeline settings UI.

    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 référentiel.

    Override YAML trigger from here.

  • Les webhooks sont utilisés pour communiquer les mises à jour de Bitbucket vers Azure Pipelines. Dans Bitbucket, accédez aux paramètres de votre dépôt, puis à Webhooks. Vérifiez que les webhooks existent.

  • Votre pipeline est-il suspendu 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.

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

Version erronée

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 de demande de tirage, le fichier YAML résultant de la fusion des branches source et cible de la demande de tirage est évalué pour voir si une build de demande de tirage doit être exécutée.