Partager via

Générer des référentiels GitHub

  • Article

Azure DevOps Services

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

Si vous débutez avec l’intégration des pipelines à GitHub, suivez les étapes décrites dans Créer votre premier pipeline. Revenez à cet article pour en savoir plus sur la configuration et la personnalisation de l’intégration entre GitHub et Azure Pipelines.

Organisations et utilisateurs

GitHub et Azure Pipelines sont deux services indépendants qui s’intègrent bien ensemble. Chacun d’entre eux a sa propre organisation et sa propre gestion des utilisateurs. Cette section propose une suggestion sur la façon de répliquer l’organisation et les utilisateurs de GitHub vers Azure Pipelines.

Organisations

La structure de GitHub se compose de comptes d’utilisateur et d’organisations qui contiennent des référentiels. Consultez la documentation de GitHub.

Structure de l’organisation GitHub

La structure d’Azure DevOps est constituée d’organisations contenant des projets. Consultez Planifier votre structure organisationnelle.

Structure de l’organisation Azure DevOps

Azure DevOps peut refléter votre structure GitHub avec :

  • Une organisation DevOps pour votre organisation GitHub ou votre compte d’utilisateur
  • DevOps Projects pour vos référentiels GitHub

Structure GitHub mappée à Azure DevOps

Pour configurer une structure identique dans Azure DevOps :

  1. Créez une organisation DevOps nommée d’après votre organisation GitHub ou votre compte d’utilisateur. Elle aura une URL comme https://dev.azure.com/your-organization.
  2. Dans l’organisation DevOps, créez des projets nommés d’après vos référentiels. Ils auront des URL comme https://dev.azure.com/your-organization/your-repository.
  3. Dans le projet DevOps, créez des pipelines nommés d’après l’organisation GitHub et le référentiel qu’ils créent, tels que your-organization.your-repository. Il est ensuite clair pour quels référentiels ils sont.

En suivant ce modèle, vos référentiels GitHub et Azure DevOps Projects auront des chemins d’URL correspondants. Par exemple :

Service URL
GitHub https://github.com/python/cpython
Azure DevOps https://dev.azure.com/python/cpython

Utilisateurs

Vos utilisateurs GitHub n’ont pas automatiquement accès à Azure Pipelines. Azure Pipelines ignore les identités GitHub. Pour cette raison, il n’existe aucun moyen de configurer Azure Pipelines pour avertir automatiquement les utilisateurs d’une défaillance de build ou d’une défaillance de validation de demande de tirage à l’aide de leur identité GitHub et de leur adresse e-mail. Vous devez créer explicitement de nouveaux utilisateurs dans Azure Pipelines pour répliquer des utilisateurs GitHub. Une fois que vous avez créé de nouveaux utilisateurs, vous pouvez configurer leurs autorisations dans Azure DevOps pour refléter leurs autorisations dans GitHub. Vous pouvez également configurer des notifications dans DevOps à l’aide de leur identité DevOps.

Rôles de l’organisation GitHub

Les rôles membres de l’organisation GitHub se trouvent à l’adresse https://github.com/orgs/your-organization/people (remplacer your-organization).

Les autorisations des membres de l’organisation DevOps se trouvent à l’adresse https://dev.azure.com/your-organization/_settings/security (remplacer your-organization).

Les rôles d’une organisation GitHub et les rôles équivalents dans une organisation Azure DevOps sont indiqués ci-dessous.

Rôle de l’organisation GitHub Équivalent de l’organisation DevOps
Propriétaire Membre de Project Collection Administrators
Gestionnaire de facturation Membre de Project Collection Administrators
Membre Membre de Project Collection Valid Users. Par défaut, le groupe membre n’est pas autorisé à créer de nouveaux projets. Pour modifier l’autorisation, définissez l’autorisation Create new projects du groupe sur Allow, ou créez un groupe avec les autorisations dont vous avez besoin.

Rôles de compte d’utilisateur GitHub

Un compte d’utilisateur GitHub a un rôle, qui est la propriété du compte.

Les autorisations des membres de l’organisation DevOps se trouvent à l’adresse https://dev.azure.com/your-organization/_settings/security (remplacer your-organization).

Le rôle de compte d’utilisateur GitHub est mappé aux autorisations de l’organisation DevOps comme suit.

Rôle de compte d’utilisateur GitHub Équivalent de l’organisation DevOps
Propriétaire Membre de Project Collection Administrators

Autorisations de référentiel GitHub

Les autorisations de référentiel GitHub se trouvent à l’adresse https://github.com/your-organization/your-repository/settings/collaboration (remplacer your-organization et your-repository).

Les autorisations du projet DevOps se trouvent à l’adresse https://dev.azure.com/your-organization/your-project/_settings/security (remplacer your-organization et your-project).

Les autorisations équivalentes entre les référentiels GitHub et Azure DevOps Projects sont les suivantes.

Autorisation de référentiel GitHub Équivalent du projet DevOps
Admin Membre de Project Administrators
Write Membre de Contributors
Lire Membre de Readers

Si votre référentiel GitHub accorde l’autorisation aux équipes, vous pouvez créer des équipes correspondantes dans la section Teams de vos paramètres de projet Azure DevOps. Ajoutez ensuite les équipes aux groupes de sécurité ci-dessus, tout comme les utilisateurs.

Autorisations spécifiques au pipeline

Pour accorder des autorisations aux utilisateurs ou aux équipes pour des pipelines spécifiques dans un projet DevOps, procédez comme suit :

  1. Visitez la page Pipelines du projet (par exemple, https://dev.azure.com/your-organization/your-project/_build).
  2. Sélectionnez le pipeline pour lequel définir des autorisations spécifiques.
  3. Dans le menu contextuel '...', sélectionnez Sécurité.
  4. Sélectionnez Ajouter... pour ajouter un utilisateur, une équipe ou un groupe spécifique et personnaliser ses autorisations pour le pipeline.

Accès aux référentiels GitHub

Vous créez un pipeline en sélectionnant d’abord un référentiel GitHub, puis un fichier YAML dans ce référentiel. Le référentiel dans lequel le fichier YAML est présent est appelé référentiel 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 référentiels.

Azure Pipelines doit avoir accès à vos référentiels pour déclencher leurs générations et extraire leur code pendant les générations.

Il y a trois types d’authentification pour accorder à Azure Pipelines l’accès à vos dépôts GitHub pendant la création d’un pipeline.

Type d'authentification Exécution de pipelines avec Fonctionne avec GitHub Checks
1. GitHub App Identité Azure Pipelines Oui
2. OAuth Votre identité GitHub personnelle No
3. Jeton d’accès personnel (PAT) Votre identité GitHub personnelle No

Authentification d’application GitHub

L’application GitHub Azure Pipelines est le type d’authentification recommandé pour les pipelines d’intégration continue. Après avoir installé l’application GitHub dans votre compte ou votre organisation GitHub, votre pipeline s’exécute sans utiliser votre identité GitHub personnelle. Les builds et les mises à jour d’état GitHub sont effectués à l’aide de l’identité Azure Pipelines. L’application fonctionne avec GitHub Checks pour afficher les résultats de build, de test et de couverture du code dans GitHub.

Pour utiliser l’application GitHub, installez-la dans votre organisation ou compte d’utilisateur GitHub pour certains référentiels ou tous les référentiels. L’application GitHub peut être installée et désinstallée à partir de la page d’accueil de l’application.

Après l’installation, l’application GitHub devient la méthode d’authentification d’Azure Pipelines par défaut sur GitHub (au lieu d’OAuth) lorsque les pipelines sont créés pour les référentiels.

Si vous installez l’application GitHub pour tous les référentiels d’une organisation GitHub, vous n’avez pas besoin de vous soucier du fait qu’Azure Pipelines envoie des e-mails de masse ou configure automatiquement des pipelines en votre nom. En guise d’alternative à l’installation de l’application pour tous les référentiels, les administrateurs de référentiels peuvent l’installer une à la fois pour les référentiels individuels. Cela nécessite davantage de travail pour les administrateurs, mais n’a aucun avantage ni inconvénient.

Autorisations nécessaires dans GitHub

L’installation de l’application GitHub Azure Pipelines nécessite que vous soyez propriétaire d’organisation GitHub ou administrateur de référentiel GitHub. En outre, pour créer un pipeline pour un référentiel GitHub avec des déclencheurs d’intégration continue et de demande de tirage, vous devez disposer des autorisations GitHub requises configurées. Sinon, le référentiel n’apparaît pas dans la liste des référentiels lors de la création d’un pipeline. Selon le type d’authentification et la propriété du référentiel, vérifiez que l’accès approprié est configuré.

  • Si le référentiel se trouve dans votre compte GitHub personnel, installez l’application GitHub Azure Pipelines dans votre compte GitHub personnel, et vous serez en mesure de répertorier ce référentiel lors de la création du pipeline dans Azure Pipelines.

  • Si le référentiel se trouve dans le compte GitHub personnel d’une autre personne, cette dernière doit installer l’application GitHub Azure Pipelines dans son compte GitHub personnel. Vous devez être ajouté en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail. Une fois cela fait, vous pouvez créer un pipeline pour ce référentiel.

  • Si le référentiel se trouve dans une organisation GitHub que vous possédez, installez l’application GitHub Azure Pipelines dans l’organisation GitHub. Vous ou votre équipe devez également être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ».

  • Si le référentiel se trouve dans une organisation GitHub appartenant à une autre personne, un propriétaire de l’organisation GitHub ou un administrateur de référentiel doit installer l’application GitHub Azure Pipelines dans l’organisation. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

Autorisations des applications GitHub

L’application GitHub demande les autorisations suivantes pendant l’installation :

Autorisation Utilisation de l’autorisation par Azure Pipelines
Accès en écriture au code Ce n’est qu’en cas d’action délibérée qu’Azure Pipelines simplifie la création d’un pipeline en validant un fichier YAML dans une branche sélectionnée de votre référentiel GitHub.
Accès en lecture aux métadonnées Azure Pipelines récupère les métadonnées GitHub pour afficher le référentiel, les branches et les problèmes associés à un build dans le résumé du build.
Accès en lecture et en écriture aux vérifications Azure Pipelines lit et écrit ses propres résultats de build, de test et de couverture du code à afficher dans GitHub.
Accès en lecture et écriture aux demandes de tirage Ce n’est qu’en cas d’action délibérée qu’Azure Pipelines simplifie la création d’un pipeline en créant une demande de tirage pour un fichier YAML validé pour une branche sélectionnée de votre référentiel GitHub. Les pipelines récupèrent les métadonnées de requête à afficher dans les résumés de build associés aux demandes de tirage.

Résolution des problèmes d’installation de l’application GitHub

GitHub peut afficher une erreur telle que :

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Cela signifie que l’application GitHub est probablement déjà installée pour votre organisation. Lorsque vous créez un pipeline pour un référentiel dans l’organisation, l’application GitHub est automatiquement utilisée pour la connexion à GitHub.

Créer des pipelines dans plusieurs organisations et projets Azure DevOps

Une fois l’application GitHub installée, les pipelines peuvent être créés pour les référentiels de l’organisation dans différents projets et organisations Azure DevOps. Toutefois, si vous créez des pipelines pour un référentiel unique dans plusieurs organisations Azure DevOps, seuls les pipelines de la première organisation peuvent être déclenchés automatiquement par des validations GitHub ou des demandes de tirage. Les builds manuels ou planifiés sont toujours possibles dans les organisations Azure DevOps secondaires.

Authentification OAuth

OAuth est le type d’authentification le plus simple à utiliser pour les dépôts dans votre compte GitHub personnel. Les mises à jour d’état GitHub sont effectuées pour le compte de votre identité GitHub personnelle. Pour que les pipelines continuent de fonctionner, l’accès à votre référentiel doit rester actif. Certaines fonctionnalités GitHub, telles que les vérifications, ne sont pas disponibles avec OAuth et nécessitent l’application GitHub.

Pour utiliser OAuth, sélectionnez Choisir une autre connexion sous la liste des référentiels lors de la création d’un pipeline. Sélectionnez ensuite Autoriser pour vous connecter à GitHub et 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.

Autorisations nécessaires dans GitHub

Pour créer un pipeline pour un référentiel GitHub avec des déclencheurs d’intégration continue et de demande de tirage, vous devez disposer des autorisations GitHub requises configurées. Sinon, le référentiel n’apparaît pas dans la liste des référentiels lors de la création d’un pipeline. Selon le type d’authentification et la propriété du référentiel, vérifiez que l’accès approprié est configuré.

  • Si le référentiel se trouve dans votre compte GitHub personnel, au moins une fois, authentifiez-vous auprès de GitHub avec OAuth à l’aide de vos informations d’identification de compte GitHub personnelles. Cela peut être effectué dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Authorize. Accordez à Azure Pipelines l’accès à vos référentiels sous « Autorisations » ici.

  • Si le référentiel se trouve dans le compte GitHub personnel d’une autre personne, au moins une fois, l’autre personne doit s’authentifier auprès de GitHub avec OAuth à l’aide de ses informations d’identification de compte GitHub personnelles. Cela peut être effectué dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Authorize. L’autre personne doit accorder à Azure Pipelines l’accès à ses référentiels sous « Autorisations » ici. Vous devez être ajouté en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

  • Si le référentiel se trouve dans une organisation GitHub que vous possédez, au moins une fois, authentifiez-vous auprès de GitHub avec OAuth à l’aide de vos informations d’identification de compte GitHub personnelles. Cela peut être effectué dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Authorize. Accordez à Azure Pipelines l’accès à votre organisation sous « Accès à l’organisation » ici. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ».

  • Si le référentiel se trouve dans l’organisation GitHub appartenant à une autre personne, au moins une fois, un propriétaire de l’organisation GitHub doit s’authentifier auprès de GitHub avec OAuth à l’aide de ses informations d’identification de compte GitHub personnelles. Cela peut être effectué dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Authorize. Le propriétaire de l’organisation doit accorder à Azure Pipelines l’accès à l’organisation sous « Accès à l’organisation » ici. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

Révoquer l’accès OAuth

Après avoir autorisé Azure Pipelines à utiliser OAuth, pour le révoquer ultérieurement et empêcher une autre utilisation, consultez Applications OAuth dans vos paramètres GitHub. Vous pouvez également le supprimer de la liste des connexions de service GitHub dans vos paramètres de projet Azure DevOps.

Authentification par jeton d’accès personnel (PAT)

Les PAT sont effectivement identiques à OAuth, mais vous permettent de contrôler quelles autorisations sont accordées à Azure Pipelines. Les builds et les mises à jour d’état GitHub sont effectués au nom de votre identité GitHub personnelle. Pour que les builds continuent de fonctionner, l’accès à votre référentiel doit rester actif.

Pour créer un PAT, visitez Jeton d’accès personnel dans vos paramètres GitHub. Les demande d’autorisations requises sont repo, admin:repo_hook, read:user et user:email. Il s’agit des mêmes autorisations requises lors de l’utilisation d’OAuth ci-dessus. Copiez le PAT généré dans le presse-papiers et collez-le dans une nouvelle connexion de service GitHub dans vos paramètres de projet Azure DevOps. Pour un rappel ultérieur, nommez la connexion de service d’après votre nom d’utilisateur GitHub. Elle sera disponible dans votre projet Azure DevOps pour une utilisation ultérieure lors de la création de pipelines.

Autorisations nécessaires dans GitHub

Pour créer un pipeline pour un référentiel GitHub avec des déclencheurs d’intégration continue et de demande de tirage, vous devez disposer des autorisations GitHub requises configurées. Sinon, le référentiel n’apparaît pas dans la liste des référentiels lors de la création d’un pipeline. Selon le type d’authentification et la propriété du référentiel, vérifiez que l’accès suivant est configuré.

  • Si le référentiel se trouve dans votre compte GitHub personnel, le PAT doit avoir les étendues d’accès requises sous Jetons d’accès personnels : repo, admin:repo_hook, read:user et user:email.

  • Si le référentiel se trouve dans le compte GitHub personnel d’une autre personne, le PAT doit avoir les étendues d’accès requises sous Jetons d’accès personnel : repo, admin:repo_hook, read:user et user:email. Vous devez être ajouté en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

  • Si le référentiel se trouve dans une organisation GitHub que vous possédez, le PAT doit avoir les étendues d’accès requises sous Jetons d’accès personnels : repo, admin:repo_hook, read:user et user:email. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ».

  • Si le référentiel se trouve dans une organisation GitHub appartenant à une autre personne, le PAT doit avoir les étendues d’accès requises sous Jetons d’accès personnels : repo, admin:repo_hook, read:user et user:email. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

Révoquer l’accès PAT

Après avoir autorisé Azure Pipelines à utiliser un PAT, pour le supprimer ultérieurement et empêcher une utilisation ultérieure, consultez Jetons d’accès personnels dans vos paramètres GitHub. Vous pouvez également le supprimer de la liste des connexions de service GitHub dans vos paramètres de projet Azure DevOps.

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

GitHub crée une nouvelle référence lorsqu’une demande de tirage est créée. La référence pointe vers une validation de fusion, qui est le code fusionné entre les branches source et cible de la demande de tirage. Le pipeline de validation de demande de tirage génère la validation vers laquelle cette référence pointe. Cela signifie que le fichier YAML utilisé pour exécuter le pipeline est également une fusion entre la branche source et la branche cible. Par conséquent, les modifications que vous apportez au fichier YAML dans la branche source de la demande de tirage peuvent remplacer le comportement défini par le fichier YAML dans la branche cible.

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 avec un sous-ensemble de branches, un pipeline est déclenché uniquement lorsque les mises à jour sont envoyées à ces branches.

Pour les déclencheurs plus complexes qui doivent exclure certaines branches, vous devez utiliser la syntaxe complète, comme indiqué dans l’exemple suivant. Dans cet exemple, les demandes de tirage ciblant main ou releases/* sont validées et la branche releases/old* est exclue.

# 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 :

  • Azure Pipelines publie un état neutre sur GitHub lorsqu’il décide de ne pas exécuter de build de validation en raison d’une règle d’exclusion de chemin d’accès. Cela fournit une direction claire vers GitHub indiquant qu’Azure Pipelines a terminé son traitement. Pour plus d’informations, consultez Publier un état neutre sur GitHub lorsqu’un build est ignoré.
  • Les caractères génériques sont désormais 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 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).
  • Azure Pipelines publie un état neutre sur GitHub lorsqu’il décide de ne pas exécuter de build de validation en raison d’une règle d’exclusion de chemin d’accès.

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

Validation de brouillon de demande de tirage

Par défaut, les déclencheurs de demande de tirage se déclenchent sur les brouillons de demandes de tirage et les demandes de tirage prêtes à être évaluées. Pour désactiver les déclencheurs de demande de tirage pour les brouillons de demandes de tirage, définissez la propriété drafts sur false.

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

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 ne se déclenche pas, suivez les étapes de résolution des problèmes dans la FAQ.

Si vous disposez d’une demande de tirage ouverte et que vous envoyez des modifications à sa branche source, plusieurs pipelines peuvent s’exécuter :

  • Les pipelines qui ont un déclencheur de demande de tirage sur la branche cible de la demande de tirage s’exécutent sur la validation de fusion (le code fusionné entre les branches source et cible de la demande de tirage), qu’il existe ou non des validations envoyées (push) dont les messages ou descriptions contiennent [skip ci] (ou l’une de ses variantes).
  • Les pipelines déclenchés par les modifications apportées à la branche source de la demande de tirage, s’il n’y a pas de validations envoyées dont les messages ou descriptions contiennent [skip ci] (ou l’une de ses variantes). Si au moins une validation envoyée contient [skip ci], les pipelines ne s’exécutent pas.

Enfin, après avoir fusionné la demande de tirage, Azure Pipelines exécute les pipelines CI déclenchés par des envois vers la branche cible, si le message ou la description de la validation de fusion ne contient pas [skip ci] (ou l’une de ses variantes).

Branches protégées

Vous pouvez exécuter un build de validation avec chaque validation ou demande de tirage qui cible une branche, et même empêcher la fusion des demandes de tirage jusqu’à ce qu’un build de validation réussisse.

Pour configurer les builds de validation obligatoires pour un référentiel GitHub, vous devez être son propriétaire, un collaborateur avec le rôle d’administrateur ou un membre de l’organisation GitHub avec le rôle d’écriture.

  1. Tout d’abord, créez un pipeline pour le référentiel et générez-le au moins une fois afin que son état soit publié sur GitHub, ce qui rend GitHub conscient du nom du pipeline.

  2. Ensuite, suivez la documentation de GitHub pour configurer des branches protégées dans les paramètres du référentiel.

    Pour la vérification de l’état, sélectionnez le nom de votre pipeline dans la liste Vérifications d’état.

    Vérification de l’état du pipeline GitHub

Important

Si votre pipeline ne s’affiche pas dans cette liste, vérifiez ce qui suit :

Contributions provenant de sources externes

Si votre référentiel GitHub est open source, vous pouvez rendre votre projet Azure DevOps public afin que tout le monde puisse afficher les résultats de build, les journaux et les résultats des tests de votre pipeline sans se connecter. Lorsque les utilisateurs en dehors de votre organisation dupliquent votre référentiel et envoient des demandes de tirage, ils peuvent afficher l’état des builds qui valident automatiquement ces demandes de tirage.

Vous devez garder à l’esprit les considérations suivantes lors de l’utilisation d’Azure Pipelines dans un projet public lors de l’acceptation des contributions provenant de sources externes.

Restrictions d'accès

Tenez compte des restrictions d’accès suivantes lorsque vous exécutez des pipelines dans des projets publics Azure DevOps :

  • Secrets : par défaut, les secrets associés à votre pipeline ne sont pas mis à la disposition des validations de demandes de tirage des duplications. Consultez Valider les contributions des duplications.
  • Accès inter-projets : tous les pipelines d’un projet public Azure DevOps s’exécutent avec un jeton d’accès limité au projet. Les pipelines d’un projet public peuvent accéder à des ressources telles que des artefacts de build ou des résultats de test uniquement dans le projet et non dans d’autres projets de l’organisation Azure DevOps.
  • Packages Azure Artifacts : si vos pipelines ont besoin d’accéder aux packages à partir d’Azure Artifacts, vous devez accorder explicitement l’autorisation au compte Project Build Service d’accéder aux flux de package.

Contributions de duplications

Important

Ces paramètres affectent la sécurité de votre pipeline.

Lorsque vous créez un pipeline, il est automatiquement déclenché pour les demandes de tirage à partir de duplications de votre référentiel. Vous pouvez modifier ce comportement, en tenant bien compte de la façon dont il affecte la sécurité. Pour activer ou désactiver ce comportement :

  1. Accédez à votre projet Azure DevOps. Sélectionnez Pipelines, recherchez votre pipeline, puis sélectionnez Modifier.
  2. Sélectionnez l’onglet Déclencheurs. Après avoir activé le déclencheur de demande de tirage, activez ou désactivez les demandes de tirage de build à partir de duplications de ce référentiel.

Par défaut, avec des pipelines GitHub, les secrets associés à votre pipeline de build ne sont pas mis à la disposition des builds de demandes de tirage de duplications. Ces secrets sont activés par défaut avec les pipelines GitHub Enterprise Server. Les secrets comprennent :

Pour contourner cette précaution sur les pipelines GitHub, activez la case à cocher Rendre les secrets disponibles pour les builds de duplications. Tenez compte de l’effet de ce paramètre sur la sécurité.

Notes

Lorsque vous activez les builds de fork pour accéder aux secrets, Azure Pipelines restreint par défaut le jeton d’accès utilisé pour les builds de fork. Il a un accès plus limité aux ressources ouvertes qu’un jeton d’accès normal. Pour accorder aux builds de duplication les mêmes autorisations que les builds standard, activez le paramètre Faire en sorte que les builds de duplication aient les mêmes autorisations que les builds standard.

Pour plus d’informations, consultez Protection du référentiel - Duplications.

Vous pouvez définir de manière centralisée la façon dont les pipelines créent des demandes de tirage à partir de référentiels GitHub forkés à l’aide du contrôle Limit building pull requests from forked GitHub repositories (Limiter les demandes de tirage de génération à partir de référentiels GitHub dupliqués). Il est disponible au niveau de l’organisation et du projet. Vous pouvez choisir de :

  • Désactiver la génération de demandes de tirage à partir de référentiels dupliqués (forkés)
  • Générer en toute sécurité des demandes de tirage à partir de référentiels dupliqués (forkés)
  • Personnaliser les règles pour la génération de demandes de tirage à partir de référentiels dupliqués (forkés)

Capture d'écran des paramètres de contrôle centralisés de la façon dont les pipelines génèrent des demandes de tirage à partir de référentiels GitHub dupliqués (forkés).

À compter de Sprint 229, pour améliorer la sécurité de vos pipelines, Azure Pipelines ne génère plus automatiquement des demandes de tirage à partir de référentiels GitHub dupliqués. Pour les nouveaux projets et organisations, la valeur par défaut du paramètre Limiter les demandes de tirage de génération à partir de référentiels GitHub dupliqués est Désactiver la génération de demandes de tirage à partir de référentiels dupliqués.

Lorsque vous choisissez l’option Securely build pull requests from forked repositories (Générer de manière sécurisée des demandes de tirage à partir de référentiels dupliqués), tous les pipelines, à l’échelle de l’organisation et du projet, ne peuvent pas mettre des secrets à la disposition des builds de demandes de tirage à partir de référentiels dupliqués (forkés), ne peuvent pas faire en sorte que ces builds disposent des mêmes autorisations que les builds normales et doivent être déclenchés par un commentaire de demande de tirage. Les projets peuvent toujours décider de ne pas autoriser les pipelines à générer de telles demandes de tirage.

Lorsque vous choisissez l’option Personnaliser, vous pouvez définir comment restreindre les paramètres de pipeline. Par exemple, vous pouvez vous assurer que tous les pipelines nécessitent un commentaire afin de générer une demande de tirage à partir d’un référentiel GitHub dupliqué (forké), lorsque la demande de tirage appartient à des membres qui ne font pas partie de l’équipe et à des non-contributeurs. Toutefois, vous pouvez choisir de les autoriser à mettre des secrets à la disposition de ces builds. Les projets peuvent décider de ne pas autoriser les pipelines à générer de telles demandes de tirage, ou de les générer de manière sécurisée, ou d’avoir des paramètres encore plus restrictifs que ce qui est spécifié au niveau de l’organisation.

Le contrôle est désactivé pour les organisations existantes. À compter de septembre 2023, Générer en toute sécurité des demandes de tirage à partir de référentiels dupliqués (fork) est activé par défaut pour les nouvelles organisations.

Considérations importantes relatives à la sécurité

Un utilisateur GitHub peut dupliquer votre référentiel, le modifier et créer une demande de tirage pour proposer des modifications à votre référentiel. Cette demande de tirage peut contenir du code malveillant à exécuter dans le cadre de votre build déclenché. Ce code peut causer des dommages de la manière suivante :

  • Fuite de secrets à partir de votre pipeline. Pour atténuer ce risque, n’activez pas la case à cocher Rendre les secrets disponibles pour les builds de référentiels si votre référentiel est public ou que des utilisateurs non approuvés peuvent envoyer des demandes de tirage qui déclenchent automatiquement des builds. qui est désactivée par défaut.

  • Compromettez l’exécution de l’agent par l’ordinateur pour voler du code ou des secrets à partir d’autres pipelines. Pour atténuer ce problème :

    • Utilisez un pool d’agents hébergés par Microsoft pour générer des demandes de tirage à partir de duplications. Les ordinateurs d’agents hébergés par Microsoft sont immédiatement supprimés une fois qu’ils ont terminé un build. Il n’y a donc aucun impact durable s’ils sont compromis.

    • Si vous devez utiliser un agent autohébergé, ne stockez pas de secrets et n’exécutez pas d’autres builds et versions qui utilisent des secrets sur le même agent, sauf si votre référentiel est privé et que vous faites confiance aux créateurs de demandes de tirage.

Déclencheurs de commentaires

Les collaborateurs du référentiel peuvent commenter une demande de tirage pour exécuter manuellement un pipeline. Voici quelques raisons courantes pour lesquelles vous souhaiterez peut-être procéder comme suit :

  • Vous ne souhaiterez peut-être pas générer automatiquement des demandes de tirage d’utilisateurs inconnus jusqu’à ce que leurs modifications puissent être examinées. Vous souhaitez qu’un des membres de votre équipe examine d’abord son code, puis exécute le pipeline. Il s’agit d’une mesure de sécurité généralement utilisée lors de la génération de code fourni à partir de référentiels dupliqués.
  • Vous pouvez exécuter une suite de tests facultative ou une build de validation supplémentaire.

Pour activer les déclencheurs de commentaire, vous devez suivre les deux étapes suivantes :

  1. Activez les déclencheurs de demande de tirage pour votre pipeline et assurez-vous que vous n’avez pas exclu la branche cible.
  2. Dans le portail web Azure Pipelines, modifiez votre pipeline et choisissez Plus d’actions, Déclencheurs. Ensuite, sous Validation de demande d’extraction, activez Exiger le commentaire d’un membre de l’équipe avant de générer une demande de tirage.
    • Choisissez Sur toutes les demandes de tirage pour exiger le commentaire d’un membre de l’équipe avant de générer une demande de tirage. Avec ce flux de travail, un membre de l’équipe examine la demande de tirage et déclenche le build avec un commentaire une fois que la demande de tirage est considérée comme sécurisée.
    • Choisissez Uniquement sur les demandes de tirage de membres n’appartenant pas à l’équipe pour exiger le commentaire d’un membre de l’équipe uniquement lorsqu’une demande de tirage est effectuée par un membre n’appartenant pas à l’équipe. Dans ce flux de travail, un membre de l’équipe n’a pas besoin d’une révision de membre d’équipe secondaire pour déclencher un build.

Avec ces deux modifications, le build de validation de demande de tirage ne sera pas déclenché automatiquement, sauf si Uniquement sur les demandes de tirage de membres n’appartenant pas à l’équipe est sélectionné et que la demande de tirage est effectuée par un membre de l’équipe. Seuls les propriétaires et collaborateurs du référentiel disposant de l’autorisation 'Écriture' peuvent déclencher le build en commentant la demande de tirage avec /AzurePipelines run ou /AzurePipelines run <pipeline-name>.

Les commandes suivantes peuvent être émises à Azure Pipelines dans les commentaires :

Commande Résultats
/AzurePipelines help Affichez l’aide pour toutes les commandes prises en charge.
/AzurePipelines help <command-name> Affichez l’aide pour la commande spécifiée.
/AzurePipelines run Exécutez tous les pipelines associés à ce référentiel et dont les déclencheurs n’excluent pas cette demande de tirage.
/AzurePipelines run <pipeline-name> Exécutez le pipeline spécifié, sauf si ses déclencheurs excluent cette demande de tirage.

Notes

Pour la concision, vous pouvez commenter à l’aide de /azp au lieu de /AzurePipelines.

Important

Les réponses à ces commandes s’affichent dans la discussion des demandes de tirage uniquement si votre pipeline utilise l’application GitHub Azure Pipelines.

Résoudre les problèmes liés aux déclencheurs de commentaires de demande de tirage

Si vous disposez des autorisations de référentiel nécessaires, mais que les pipelines ne sont pas déclenchés par vos commentaires, assurez-vous que votre appartenance est publique dans l’organisation du référentiel ou ajoutez-vous directement en tant que collaborateur de référentiel. Les pipelines ne peuvent pas voir les membres d’une organisation privée, sauf s’ils sont des collaborateurs directs ou qu’ils appartiennent à une équipe qui est un collaborateur direct. Vous pouvez modifier l’appartenance de votre organisation GitHub de privée à publique ici (remplacez Your-Organization par le nom de votre organisation) : https://github.com/orgs/Your-Organization/people.

Exécutions 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 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.

Capture d’écran d’une exécution de pipeline d’information.

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 d’information.

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. Lorsque le build est supprimé manuellement ou via une stratégie de rétention, la balise est également supprimée.

Variables prédéfinies

Lorsque vous générez un référentiel GitHub, la plupart des variables prédéfinies sont disponibles pour vos travaux. Toutefois, étant donné qu’Azure Pipelines ne reconnaît pas l’identité d’un utilisateur effectuant une mise à jour dans GitHub, les variables suivantes sont définies sur l’identité système au lieu de l’identité de l’utilisateur :

  • Build.RequestedFor
  • Build.RequestedForId
  • Build.RequestedForEmail

Mises à jour d’état

Il existe deux types d’états publiés par Azure Pipelines sur GitHub : les états de base et les exécutions de vérification GitHub. La fonctionnalité Vérifications GitHub est disponible uniquement avec les applications GitHub.

Les états du pipeline s’affichent à différents endroits dans l’interface utilisateur GitHub.

  • Pour les demandes de tirage, ils sont affichés sous l’onglet Conversations de demande de tirage.
  • Pour les validations individuelles, ils sont affichés lors du pointage sur la marque d’état après l’heure de validation sous l’onglet Validations du référentiel.

Connexions PAT ou OAuth GitHub

Pour les pipelines utilisant des connexions PAT ou GitHub OAuth, les états sont renvoyés à la validation/demande de tirage qui a déclenché l’exécution. L’API d’état GitHub est utilisée pour publier ces mises à jour. Ces états contiennent des informations limitées : état du pipeline (échec, réussite), URL pour revenir au pipeline de build et une brève description de l’état.

Les états des connexions PAT ou GitHub OAuth ne sont envoyés qu’au niveau de l’exécution. En d’autres termes, vous pouvez avoir un état unique mis à jour pour une exécution entière. Si vous avez plusieurs travaux dans une exécution, vous ne pouvez pas publier d’état distinct pour chaque travail. Toutefois, plusieurs pipelines peuvent publier des états distincts dans la même validation.

Vérifications GitHub

Pour les pipelines configurés à l’aide de l’application GitHub Azure Pipelines, l’état est publié sous la forme de vérifications GitHub. Les vérifications GitHub permettent d’envoyer des informations détaillées sur l’état et le test du pipeline, la couverture du code et les erreurs. L’API Vérifications GitHub est disponible ici.

Pour chaque pipeline utilisant l’application GitHub, les vérifications sont publiées pour l’exécution globale et chaque travail dans cette exécution.

GitHub autorise trois options quand une ou plusieurs exécutions de vérification échouent pour une demande de tirage/validation. Vous pouvez choisir de « réexécuter » la vérification individuelle, toutes les vérifications ayant échoué sur cette demande/validation, ou toutes les vérifications, qu’elles aient réussi initialement ou non.

Réexécution des vérifications GitHub

En cliquant sur le lien « Réexécuter » à côté du nom Vérifier l’exécution, Azure Pipelines tente à nouveau l’exécution qui a généré l’exécution de vérification. L’exécution résultante aura le même numéro d’exécution et utilisera la même version du code source, de la configuration et du fichier YAML que le build initial. Seuls les travaux qui ont échoué dans l’exécution initiale et tous les travaux en aval dépendants seront réexécutés. Cliquer sur le lien « Réexécuter toutes les vérifications ayant échoué » aura le même effet. Il s’agit du même comportement que de cliquer sur « Nouvelle tentative d’exécution » dans l’interface utilisateur d’Azure Pipelines. Le fait de cliquer sur « Réexécuter toutes les vérifications » entraîne une nouvelle exécution, avec un nouveau numéro d’exécution et récupère les modifications dans la configuration ou le fichier YAML.

Limites

  • Pour de meilleures performances, nous recommandons un maximum de 50 pipelines dans un seul dépôt. Pour des performances acceptables, nous recommandons un maximum de 100 pipelines dans un seul dépôt. Le temps nécessaire pour effectuer un envoi (push) vers un référentiel augmente avec le nombre de pipelines de ce dernier. Chaque fois qu’il y a un envoi vers un référentiel, Azure Pipelines doit charger tous les pipelines YAML dans ce référentiel pour déterminer si l’un d’entre eux doit s’exécuter, et le chargement de chaque pipeline entraîne une pénalité de performances. En plus des problèmes de performances, l’utilisation d’un trop grand nombre de pipelines dans un référentiel unique peut entraîner une limitation côté GitHub, car Azure Pipelines peut effectuer trop de requêtes dans un court laps de temps.

  • L’utilisation de modèles d'extension et d'inclusion dans un pipeline affecte le taux auquel Azure Pipelines effectue des requêtes d’API GitHub et peut entraîner une limitation côté GitHub. Avant d’exécuter un pipeline, Azure Pipelines doit générer le code YAML complet. Il doit donc extraire tous les fichiers de modèle.

  • Azure Pipelines charge un maximum de 2000 branches à partir d’un référentiel dans les listes déroulantes du portail Azure DevOps, par exemple dans la fenêtre Sélectionner une branche pour le paramètre Branche par défaut pour les builds manuels et planifiés, ou lors du choix d’une branche lors de l’exécution d’un pipeline manuellement.

    Si vous ne voyez pas la branche souhaitée dans la liste, tapez manuellement le nom de la branche souhaitée dans le champ Branche par défaut pour les builds manuels et planifiés.

    Si vous cliquez sur l’ellipse et ouvrez le dialogue Sélectionner une branche puis le fermez sans choisir une branche valide dans la liste déroulante, vous pouvez voir un message Certains paramètres nécessitent une attention particulière et un message Ce paramètre est requis sous Branche par défaut pour les builds manuels et planifiés. Pour contourner ce message, rouvrez le pipeline et saisissez directement le nom dans le champ Branche par défaut pour les builds manuels et planifiés.

Forum aux questions

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

  • Types de connexion : je ne sais pas quel type de connexion j’utilise pour connecter mon pipeline à GitHub.
  • Déclencheurs défaillants : mon pipeline n’est pas déclenché lorsque j’envoie une mise à jour au référentiel.
  • Échec de 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.
  • Mises à jour d’état manquantes : mes demandes de tirage GitHub sont bloquées, car Azure Pipelines n’a pas signalé de mise à jour d’état.

Types de connexion

Pour résoudre les problèmes de déclencheurs, comment savoir quel type de connexion GitHub j’utilise pour mon pipeline ?

La résolution des problèmes liés aux déclencheurs dépend beaucoup du type de connexion GitHub que vous utilisez dans votre pipeline. Il existe deux façons de déterminer le type de connexion : à partir de GitHub et à partir d’Azure Pipelines.

  • À partir de GitHub : si un référentiel est configuré pour utiliser l’application GitHub, les états sur les demandes de tirage et les validations sont Vérifier les exécutions. Si le référentiel dispose d’Azure Pipelines configuré avec des connexions OAuth ou PAT, les états sont le style « ancien » des états. Un moyen rapide de déterminer si les états sont Vérifier les exécutions ou les états simples consiste à examiner l’onglet « conversation » sur une demande de tirage GitHub.

    • Si le lien « Détails » redirige vers l’onglet Vérifications, il s’agit d’une exécution de vérification et le référentiel utilise l’application.
    • Si le lien « Détails » redirige vers le pipeline Azure DevOps, l’état est un état « ancien style » et le référentiel n’utilise pas l’application.

  • À partir d’Azure Pipelines : vous pouvez également déterminer le type de connexion en inspectant le pipeline dans l’interface utilisateur d’Azure Pipelines. Ouvrez l’éditeur du pipeline. Sélectionnez Déclencheurs pour ouvrir l’éditeur classique du pipeline. Ensuite, sélectionnez l’onglet YAML, puis l’étape Sources get. Vous remarquerez une bannière Autorisée à l’aide de la connexion : indiquant la connexion de service utilisée pour intégrer le pipeline à GitHub. Le nom de la connexion de service est un lien hypertexte. Sélectionnez-le pour accéder aux propriétés de connexion de service. Les propriétés de la connexion de service indiquent le type de connexion utilisé :

    • L’application Azure Pipelines indique la connexion de l’application GitHub
    • oauth indique la connexion OAuth
    • personalaccesstoken indique l’authentification PAT

Comment changer mon pipeline pour utiliser l’application GitHub au lieu d’OAuth ?

L’utilisation d’une application GitHub au lieu d’une connexion OAuth ou PAT est l’intégration recommandée entre GitHub et Azure Pipelines. Pour passer à l’application GitHub, procédez comme suit :

  1. Naviguez ici et installez l’application dans l’organisation GitHub de votre référentiel.
  2. Pendant l’installation, vous êtes redirigé vers Azure DevOps pour choisir une organisation et un projet Azure DevOps. Choisissez l’organisation et le projet qui contiennent le pipeline de build classique pour lequel vous souhaitez utiliser l’application. Ce choix associe l’installation de l’application GitHub à votre organisation Azure DevOps. Si vous choisissez incorrectement, vous pouvez visiter cette page pour désinstaller l’application GitHub de votre organisation GitHub et recommencer.
  3. Dans la page suivante qui s’affiche, vous n’avez pas besoin de poursuivre avec la création d’un pipeline.
  4. Modifiez votre pipeline en accédant à la page Pipelines (par exemple, https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), en sélectionnant votre pipeline, puis en cliquant sur Modifier).
  5. S’il s’agit d’un pipeline YAML, sélectionnez le menu Déclencheurs pour ouvrir l’éditeur classique.
  6. Sélectionnez l’étape « Sources get » dans le pipeline.
  7. Dans la barre verte avec le texte « Autorisé à l’aide de la connexion », sélectionnez « Modifier », puis sélectionnez la connexion d’application GitHub portant le même nom que l’organisation GitHub dans laquelle vous avez installé l’application.
  8. Dans la barre d’outils, sélectionnez « Enregistrer et mettre en file d’attente », puis « Enregistrer et mettre en file d’attente ». Sélectionnez le lien vers l’exécution du pipeline qui a été mis en file d’attente pour vous assurer qu’il réussit.
  9. Créez (ou fermez et rouvrez) une demande de tirage dans votre référentiel GitHub pour vérifier qu’un build est correctement mis en file d’attente dans sa section « Vérifications ».

Pourquoi aucun référentiel GitHub ne s’affiche-t-il pour me permettre de choisir dans Azure Pipelines ?

Selon le type d’authentification et la propriété du référentiel, des autorisations spécifiques sont requises.

Lorsque je sélectionne un référentiel lors de la création du pipeline, j’obtiens une erreur « Le référentiel {nom-du-référentiel} est utilisé avec l’application GitHub Azure Pipelines dans une autre organisation Azure DevOps. »

Cela signifie que votre référentiel est déjà associé à un pipeline dans une autre organisation. Les événements CI et PR de ce référentiel ne fonctionnent pas, car ils seront remis à l’autre organisation. Voici les étapes à suivre pour supprimer le mappage à l’autre organisation avant de procéder à la création d’un pipeline.

  1. Ouvrez une demande de tirage (pull request) dans votre référentiel GitHub et faites le commentaire /azp where. Cela renvoie à l’organisation Azure DevOps à laquelle le référentiel est mappé.

  2. Pour modifier le mappage, désinstallez l’application de l’organisation GitHub et réinstallez-la. Lorsque vous la réinstallez, veillez à sélectionner la bonne organisation lorsque vous êtes redirigé vers Azure DevOps.

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

  • Utilisez-vous la connexion de l’application GitHub pour connecter le pipeline à GitHub ? Consultez Types de connexion pour déterminer le type de connexion dont vous disposez. Si vous utilisez une connexion d’application GitHub, procédez comme suit :

    • Le mappage est-il configuré correctement entre GitHub et Azure DevOps ? Ouvrez une demande de tirage (pull request) dans votre référentiel GitHub et faites le commentaire /azp where. Cela renvoie à l’organisation Azure DevOps à laquelle le référentiel est mappé.

      • Si aucune organisation n’est configurée pour générer ce référentiel à l’aide de l’application, accédez à https://github.com/<org_name>/<repo_name>/settings/installations et terminez la configuration de l’application.

      • Si une autre organisation Azure DevOps est signalée, cela signifie qu’une personne a déjà établi un pipeline pour ce référentiel dans une autre organisation. Nous avons actuellement la limitation nous empêchant de mapper plus d’un référentiel GitHub à une seule organisation DevOps. Seuls les pipelines de la première organisation Azure DevOps peuvent être déclenchés automatiquement. Pour modifier le mappage, désinstallez l’application de l’organisation GitHub et réinstallez-la. Lorsque vous la réinstallez, veillez à sélectionner la bonne organisation lorsque vous êtes redirigé vers Azure DevOps.

  • Utilisez-vous OAuth ou PAT pour connecter le pipeline à GitHub ? Consultez Types de connexion pour déterminer le type de connexion dont vous disposez. Si vous utilisez une connexion GitHub, procédez comme suit :

    1. Les connexions OAuth et PAT s’appuient sur des webhooks pour communiquer les mises à jour vers Azure Pipelines. Dans GitHub, accédez aux paramètres de votre référentiel, puis à Webhooks. Vérifiez que les webhooks existent. En règle générale, vous devez voir trois webhooks : push, pull_request et issue_comment. Si ce n’est pas le cas, vous devez recréer la connexion de service et mettre à jour le pipeline pour utiliser la nouvelle connexion de service.

    2. Sélectionnez chacun des webhooks dans GitHub et vérifiez que la charge utile correspondant à la validation de l’utilisateur existe et a été envoyée avec succès à Azure DevOps. Vous pouvez voir une erreur ici si l’événement n’a pas pu être communiqué à Azure DevOps.

  • Le trafic d’Azure DevOps peut être limité par GitHub. Quand Azure Pipelines reçoit une notification de GitHub, il tente de contacter GitHub et d’extraire plus d’informations sur le référentiel et le fichier YAML. Si vous disposez d’un référentiel avec un grand nombre de mises à jour et de demandes de tirage, cet appel peut échouer en raison de cette limitation. Dans ce cas, vérifiez si vous pouvez réduire la fréquence des builds à l’aide d’un traitement par lots plus strict/de filtres de branche.

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

Tout d’abord, suivez les étapes de résolution des problèmes décrites dans la question précédente, puis procédez comme suit :

  • Avez-vous des conflits de fusion dans votre demande de tirage ? Pour une PR 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 un délai en regardant si le problème est spécifique à un pipeline unique ou s’il est commun à tous les pipelines ou référentiels 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. Voici quelques raisons pour lesquelles un retard peut se produire :

    • Nous avons une panne de service dans 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.
    • Votre dépôt contient trop de pipelines YAML. Pour de meilleures performances, nous recommandons un maximum de 50 pipelines dans un seul dépôt. Pour des performances acceptables, nous recommandons un maximum de 100 pipelines dans un seul dépôt. Plus il y a de pipelines, plus le traitement d’un envoi push vers ce dépôt est lent. Chaque fois qu’il y a un envoi push vers un dépôt, Azure Pipelines doit charger tous les pipelines YAML dans ce référentiel pour déterminer si l’un d’eux doit s’exécuter, et chaque nouvelle pipeline entraîne une pénalité de performances.

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.

Échec de la validation

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

remote: Repository not found.
fatal: repository <repo> not found

Cela peut être dû à une panne de GitHub. Essayez d’accéder au référentiel dans GitHub et vérifiez que vous êtes en mesure de le faire.

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 un build de demande de tirage doit être exécuté.

Mises à jour d’état manquantes

Ma demande de tirage dans GitHub est bloquée, car Azure Pipelines n’a pas mis à jour l’état.

Il peut s’agir d’une erreur temporaire qui a entraîné l’impossibilité pour Azure DevOps de communiquer avec GitHub. Réessayez d’archiver GitHub si vous utilisez l’application GitHub. Ou faites une mise à jour triviale de la demande de tirage pour voir si le problème peut être résolu.