Créer des référentiels Bitbucket Cloud

Azure DevOps Services

Azure Pipelines peut générer et valider automatiquement chaque demande de tirage et valider 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

YAML

Vous créez un pipeline en sélectionnant d’abord un référentiel Bitbucket Cloud, puis un fichier YAML dans ce référentiel. Le référentiel dans lequel le fichier YAML est présent est appelé self référentiel. Par défaut, il s’agit du référentiel 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 d’extraction de référentiels multiples.

Classique

Vous créez un pipeline en sélectionnant d’abord Bitbucket Cloud pour le type de référentiel, puis l’un des référentiels auxquels vous avez accès.

Azure Pipelines doit être autorisé à accéder à vos référentiels pour extraire le code pendant les builds. En outre, l’utilisateur qui configure le pipeline doit avoir 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 référentiels Bitbucket Cloud lors de la création d’un pipeline.

Type d’authentification	Les pipelines s’exécutent à l’aide de
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 référentiels de votre compte Bitbucket. Les mises à jour de l’état bitbucket sont effectuées au nom de votre identité Bitbucket personnelle. Pour que les pipelines continuent de fonctionner, l’accès à votre référentiel doit rester actif.

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

Remarque

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 de l’état Bitbucket sont effectuées pour le compte de votre identité personnelle. Pour que les builds continuent de fonctionner, l’accès à votre référentiel doit rester actif.

Pour créer une connexion de mot de passe, visitez 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 balises spécifiées.

YAML

Les pipelines YAML sont configurés par défaut avec un déclencheur CI sur toutes les branches, sauf si le Désactiver le paramètre de déclencheur YAML CI implicite, introduit dans sprint Azure DevOps 227, est activé. Le Désactiver le déclencheur YAML CI implicite paramètre peut être configuré au niveau de l’organisation ou au niveau du projet. Lorsque le paramètre Désactiver le déclencheur CI YAML 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/*). Consultez caractères génériques pour plus d’informations sur la syntaxe générique.

Remarque

Vous ne pouvez pas utiliser variables dans les déclencheurs, car les variables sont évaluées au moment de l’exécution (une fois le déclencheur déclenché).

Remarque

Si vous utilisez 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 illustré 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 à main ou à une branche releases. Toutefois, elle ne sera pas déclenchée si une modification est apportée à une branche releases qui commence par old.

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

En plus de spécifier des noms de branche dans les listes de branches, vous pouvez également configurer des déclencheurs en fonction des balises à l’aide du 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 Désactiver le déclencheur YAML CI implicite n’est pas activé, la valeur par défaut est comme si vous avez écrit :

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 uniquement les push vers les branches qui sont explicitement configurées pour être incluses déclenchent un pipeline. Les inclusions sont traitées en premier, puis les exclusions sont supprimées de cette liste.

Exécutions ci par lot

Si vous avez de nombreux membres de l’équipe qui 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

Remarque

batch n’est pas pris en charge dans les déclencheurs de ressources de référentiel.

Pour clarifier cet exemple, supposons qu’une A push vers main a provoqué l’exécution du pipeline ci-dessus. Pendant que ce pipeline est en cours d’exécution, des push supplémentaires B et des C se produisent dans le référentiel. 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, toutes les poussées jusqu’à ce point de temps sont regroupées par lots et une nouvelle exécution est démarrée.

Remarque

Si le pipeline a plusieurs travaux et étapes, la première exécution doit toujours atteindre un état de terminal en effectuant ou en ignorant tous ses travaux et étapes avant que la deuxième exécution puisse démarrer. Pour cette raison, vous devez faire preuve de prudence lors de l’utilisation de cette fonctionnalité dans un pipeline avec plusieurs étapes ou approbations. Si vous souhaitez traiter vos builds par lots dans de tels cas, il est recommandé de fractionner votre processus CI/CD en deux pipelines : un pour la génération (avec traitement par lots) et un pour les déploiements.

Chemins

Vous pouvez spécifier des chemins d’accès de fichier à 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 des branches à déclencher si vous utilisez Azure DevOps Server 2019.1 ou une version antérieure. Vous ne pouvez pas déclencher un pipeline avec un filtre de chemin d’accès uniquement ; vous devez également avoir 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 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 d’accès. Par exemple, vous pouvez inclure tous les chemins d’accès qui correspondent src/app/**/myapp*. Vous pouvez utiliser des caractères génériques (**, *ou ?) lors de la spécification de filtres de chemin d’accès.

• Les chemins d’accès sont toujours spécifiés par rapport à la racine du référentiel.
• 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 également l’inclure, sauf si vous le qualifiez dans un dossier plus approfondi. 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 le même cas que les dossiers réels.
• Vous ne pouvez pas utiliser variables dans les chemins, car les variables sont évaluées au moment de l’exécution (une fois le déclencheur déclenché).

Remarque

Pour les dépôts Bitbucket Cloud, l’utilisation de branches syntaxe est la seule façon de spécifier des déclencheurs de balise. 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 de cette branche est évalué pour déterminer si une exécution CI doit être démarrée.

Classique

Remarque

La variable Build.SourceVersionMessage ne fonctionne pas avec les référentiels Bitbucket lorsque Batch change pendant qu’une build est en cours est activée.

Sélectionnez Activer les d’intégration continue sous l’onglet Déclencheurs pour activer ce déclencheur si vous souhaitez que la build s’exécute chaque fois qu’une personne vérifie du code.

Modifications par lot

Activez cette case à cocher si vous avez de nombreux membres de l’équipe qui chargent souvent des modifications et que vous souhaitez réduire le nombre de builds que vous exécutez. Si vous sélectionnez cette option, lorsqu’une build est en cours d’exécution, le système attend que l’exécution soit terminée, puis met en file d’attente une autre exécution de toutes les modifications qui n’ont pas encore été générées.

Vous pouvez regrouper les modifications et les générer ensemble.

Remarque

Si vous utilisez le traitement par lots avec un pipeline YAML à plusieurs étapes, une exécution doit atteindre un état de terminal avant que le prochain puisse commencer. Cela n’est souvent pas souhaitable, car un pipeline à plusieurs étapes peut passer par des approbations et des phases de déploiement de longue durée. Dans ces cas, il est recommandé de suivre l’une des solutions suivantes :

• n’utilisez pas le traitement par lots
• fractionner le pipeline en deux pipelines distincts : un pour CI et un CD
• définir les conditions appropriées sur les étapes pour les ignorer et mettre rapidement fin à une exécution

Filtres de branche

Vous pouvez spécifier les branches dans lesquelles vous souhaitez déclencher des builds. Si vous souhaitez utiliser des caractères génériques, tapez la spécification de branche (par exemple, features/modules/*) puis appuyez sur Entrée.

Filtres de chemin d’accès

Si votre dépôt Git se trouve dans Azure Repos ou TFS, vous pouvez également spécifier des filtres de chemin pour réduire l’ensemble de fichiers que vous souhaitez déclencher une build.

Conseils :

• Les chemins d’accès sont toujours spécifiés par rapport à la racine du référentiel.
• 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 également l’inclure, sauf si vous le qualifiez dans un dossier plus approfondi. 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 le même cas que les dossiers réels.

Exemple :

Par exemple, vous souhaitez que votre build soit déclenchée par des modifications dans main et la plupart, mais pas toutes, de vos branches de fonctionnalités. Vous ne souhaitez pas non plus que les builds soient déclenchées par des modifications apportées aux fichiers dans le dossier outils.

Ignorer ci pour les validations individuelles

Vous pouvez également indiquer à Azure Pipelines d’ignorer l’exécution d’un pipeline qu’un push déclencherait normalement. Incluez simplement [skip ci] dans le message ou la description de l’une des validations qui font partie d’un push, et Azure Pipelines ignore l’exécution de l’intégration continue pour ce push. Vous pouvez également utiliser l’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 s’agit d’un scénario courant pour exécuter différentes étapes, travaux ou étapes dans votre pipeline en fonction du type de déclencheur qui a démarré l’exécution. Vous pouvez le faire à l’aide de la variable système Build.Reason. Par exemple, ajoutez la condition suivante à votre étape, travail ou étape pour l’exclure des validations de demande de tirage.

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

Comportement des déclencheurs lorsque de nouvelles branches sont envoyées (push)

Il est courant de configurer plusieurs pipelines pour le même référentiel. 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 à déclencher lorsque vous envoyez une mise à jour à votre code d’application. Dans ces cas, vous devez comprendre comment les pipelines sont déclenchés lors de la création d’une nouvelle branche.

Voici le comportement lorsque vous envoyez une nouvelle branche (qui correspond aux filtres de branche) vers votre référentiel :

• 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 balise ou un chemin, 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 seul caractère.

• Si vous démarrez 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, notamment 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 inférieur, vous pouvez inclure * comme caractère final, mais il ne fait rien de différent de spécifier le nom du répertoire lui-même. Vous pouvez pas inclure * au milieu d’un filtre de chemin d’accès, et vous n’utilisez peut-être pas ?.

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Déclencheurs de demande de tirage

Les déclencheurs de demande de tirage (PULL) entraînent l’exécution d’un pipeline chaque fois qu’une demande de tirage est ouverte avec l’une des branches cibles spécifiées ou lorsque des mises à jour sont apportées à une telle demande de tirage.

YAML

Branches

Vous pouvez spécifier les branches cibles lors de la validation de vos demandes de tirage. Par exemple, pour valider les demandes de tirage qui ciblent master et releases/*, vous pouvez utiliser le déclencheur de 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/*).

Remarque

Vous ne pouvez pas utiliser variables dans les déclencheurs, car les variables sont évaluées au moment de l’exécution (une fois le déclencheur déclenché).

Remarque

Si vous utilisez 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 des demandes de tirage dans d’autres référentiels (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 pr déclencheurs n’apparaît dans votre fichier YAML, les validations de demande de tirage sont automatiquement activées pour toutes les branches, comme si vous avez écrit le déclencheur pr suivant. Cette configuration déclenche une génération quand une demande de tirage est créée et lorsque les validations entrent dans la branche source de toute 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 de pr implicite par défaut, et seuls les envois (push) vers les branches qui sont 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 illustré dans l’exemple suivant.

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

Chemins

Vous pouvez spécifier des chemins d’accès de fichier à 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 référentiel.
• 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 également l’inclure, sauf si vous le qualifiez dans un dossier plus approfondi. 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 le même cas que les dossiers réels.
• Vous ne pouvez pas utiliser variables dans les chemins, car les variables sont évaluées au moment de l’exécution (une fois le déclencheur déclenché).

Mises à jour de tirage multiples

Vous pouvez spécifier si des 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. La valeur par défaut est 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 lede schéma YAML .

Remarque

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

Classique

Activez la case à cocher validation de demande de tirage (pull request) déclencheur et cochez la case Activer la validation des demandes de tirage (pull request) pour activer les builds sur les demandes de tirage.

Vous pouvez spécifier des branches à inclure et exclure. Sélectionnez un nom de branche dans le menu déroulant, puis sélectionnez Inclure ou Exclure le cas échéant. Pour les branches incluses, une build est déclenchée sur chaque push vers une demande de tirage ciblant cette branche.

Séances d'information

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 push. Il 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, avec une limitation fréquente de la demande par le fournisseur de référentiel Git. L’existence d’une exécution informationnelle 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.

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

• L’état est Canceled
• La durée est < 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
• Aucune étape / travaux / étapes

En savoir plus sur exécutions d’informations.

Limites

Azure Pipelines charge au maximum 2000 branches à partir d’un référentiel dans des listes déroulantes dans le portail Azure Devops, par exemple dans la branche branche par défaut pour les builds manuelles et planifiées paramètre, 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 manuellement le nom de la branche souhaitée.

Questions fréquentes (FAQ)

Les problèmes liés à l’intégration de Bitbucket se trouvent dans les 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 vos déclencheurs défaillants :

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

  

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

  

• Les webhooks sont utilisés pour communiquer les mises à jour de Bitbucket vers Azure Pipelines. Dans Bitbucket, accédez aux paramètres de votre référentiel, puis aux 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 à 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 correcte ? Si vous envoyez une mise à jour à une branche, le fichier YAML de cette même branche régit le comportement CI. Si vous envoyez une mise à jour à une branche source, le fichier YAML résultant de la fusion de la branche source avec la branche cible régit le comportement de demande de tirage. Vérifiez que le fichier YAML dans la branche correcte 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 d’inclusion et d’exclusion pour les branches, les balises et les chemins d’accès. Vérifiez que la clause Include correspond aux détails de votre validation et que la clause d’exclusion ne les exclut pas. Vérifiez la syntaxe des déclencheurs et assurez-vous qu’il est exact.

• 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, vérifiez 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 les chemins auxquels vous avez envoyé vos modifications ? Testez en envoyant une modification à un chemin inclus dans une branche incluse. Notez que les chemins d’accès dans les déclencheurs respectent la casse. Veillez à utiliser le même cas que ceux des dossiers réels lors de la spécification des chemins d’accès dans les déclencheurs.

• Avez-vous juste poussé une nouvelle branche ? Si c’est le 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 correctement. Mais ils ont cessé de travailler maintenant.

Tout d’abord, passez par les étapes de résolution des problèmes dans 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ésolvez le conflit de fusion.

• Rencontrez-vous un retard dans le traitement des événements Push ou PR ? Vous pouvez généralement vérifier cela en vérifiant si le problème est spécifique à un seul pipeline ou est commun à tous les pipelines ou dépôts de votre projet. Si une mise à jour push ou pr vers 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 doit déjà commencer à travailler dessus. Consultez fréquemment la page pour connaître les 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 puis-je le faire ?

Les utilisateurs disposant d’autorisations 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 (push) cette mise à jour vers une fonctionnalité ou une branche 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. Modifiez le pipeline dans l’interface utilisateur d’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 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 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.