Créer des référentiels GitHub

Azure DevOps Services

Azure Pipelines peut générer et valider automatiquement chaque demande de tirage et valider 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. Chacune d’entre elles possède sa propre organisation et sa propre gestion des utilisateurs. Cette section recommande de répliquer l’organisation et les utilisateurs de GitHub vers Azure Pipelines.

Organisations

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

La structure d’Azure DevOps se compose de organisations qui contiennent des projets . Consultez Planifier votre structure organisationnelle.

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

Pour configurer une structure identique dans Azure DevOps :

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

En suivant ce modèle, vos dépôts 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 d’organisation GitHub

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

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

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

Rôle d’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 des 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 à https://dev.azure.com/your-organization/_settings/security (remplacez 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 à https://github.com/your-organization/your-repository/settings/collaboration (remplacez your-organization et your-repository).

Les autorisations de projet DevOps se trouvent à https://dev.azure.com/your-organization/your-project/_settings/security (remplacez your-organization et your-project).

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

Autorisation de dépôt GitHub	Équivalent du projet DevOps
Admin	Membre de Project Administrators
Écrire	Membre de Contributors
Lire	Membre de Readers

Si votre dépôt 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. Ensuite, ajoutez 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... 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 dépôt GitHub, puis un fichier YAML dans ce référentiel. Le référentiel dans lequel le fichier YAML est présent est appelé self référentiel. Par défaut, il s’agit du référentiel que votre pipeline génère.

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

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

Azure Pipelines doit être autorisé à accéder à vos référentiels pour déclencher leurs builds et extraire leur code pendant les builds.

Il existe trois types d’authentification pour accorder à Azure Pipelines l’accès à vos référentiels GitHub lors de la création d’un pipeline.

Type d’authentification	Les pipelines s’exécutent à l’aide de	Fonctionne avec GitHub Checks
1. application GitHub	Identité Azure Pipelines	Oui
2. OAuth	Votre identité GitHub personnelle	Non
3. jeton d’accès personnel (PAT)	Votre identité GitHub personnelle	Non

Authentification d’application GitHub

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

Pour utiliser l’application GitHub, installez-la dans votre organisation GitHub ou compte d’utilisateur pour certains dépôts ou tous les dépôts. 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 par défaut d’Azure Pipelines 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 dépôts d’une organisation GitHub, vous n’avez pas besoin de vous soucier d’Azure Pipelines envoyant des e-mails de masse ou de configurer automatiquement des pipelines en votre nom. Toutefois, si l’application est installée pour tous les référentiels, le jeton utilisé par l’application a accès à tous les référentiels, y compris ceux privés. Pour des raisons de sécurité, il est recommandé de séparer les dépôts privés et publics au niveau de l’organisation. Cela signifie avoir une organisation dédiée uniquement pour les projets publics sans référentiels privés. Si, pour une raison quelconque, il est nécessaire d’avoir des référentiels publics et privés dans la même organisation, au lieu d’utiliser l’accès pour tous les référentiels, sélectionnez explicitement les référentiels auxquels l’application doit avoir accès. Cela nécessite davantage de travail pour les administrateurs, mais garantit une meilleure gestion de la sécurité.

Autorisations nécessaires dans GitHub

L’installation de l’application GitHub Azure Pipelines nécessite que vous soyez propriétaire 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 et de demande de tirage continus, 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 dépôt 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 dépôt se trouve dans le compte GitHub personnel d’une autre personne, l’autre personne 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 que vous l’avez fait, vous pouvez créer un pipeline pour ce référentiel.

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

• Si le dépôt se trouve dans une organisation GitHub propriétaire d’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 devez être ajouté en tant que collaborateur, ou votre équipe doit être ajoutée, 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 d’application GitHub

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

Autorisation	Utilisation d’Azure Pipelines par l’autorisation
Accès en écriture au code	Uniquement lors de votre action délibérée, Azure Pipelines simplifie la création d’un pipeline en commitant un fichier YAML dans une branche sélectionnée de votre dépôt 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 à une build dans le résumé de la build.
Accès en lecture et é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	Uniquement lors de votre action délibérée, Azure Pipelines simplifie la création d’un pipeline en créant une demande de tirage (pull request) pour un fichier YAML validé dans une branche sélectionnée de votre dépôt 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 d’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 se connecter à 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 dépôts de l’organisation dans différentes organisations et projets 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 manuelles ou planifiées 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 est enregistrée dans votre projet Azure DevOps pour une utilisation ultérieure et utilisée 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 et de demande de tirage continus, 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 dépôt 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. Vous pouvez le faire dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Autoriser. Accordez à Azure Pipelines l’accès à vos référentiels sous « Autorisations » ici.

• Si le dépôt 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. Vous pouvez le faire dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Autoriser. 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 dépôt 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. Vous pouvez le faire dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Autoriser. Accordez à Azure Pipelines l’accès à votre organisation sous « Accès à l’organisation » ici. Vous devez être ajouté en tant que collaborateur, ou votre équipe doit être ajoutée, dans les paramètres du référentiel sous « Collaborateurs et équipes ».

• Si le dépôt se trouve dans une organisation GitHub qui possède 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. Vous pouvez le faire dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Autoriser. Le propriétaire de l’organisation doit accorder à Azure Pipelines l’accès à l’organisation sous « Accès de l’organisation » ici. Vous devez être ajouté en tant que collaborateur, ou votre équipe doit être ajoutée, 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, visitez applications OAuth dans vos paramètres GitHub. Vous pouvez également la 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)

pats sont effectivement identiques à OAuth, mais vous permettent de contrôler les autorisations accordées à Azure Pipelines. Les builds et les mises à jour d’état GitHub sont effectuées 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 pater, visitez jetons d’accès personnels dans vos paramètres GitHub. Les autorisations requises sont repo, admin:repo_hook, read:useret 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 après votre nom d’utilisateur GitHub. Il 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 et de demande de tirage continus, 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 dépôt se trouve dans votre compte GitHub personnel, le mot de passe doit avoir les étendues d’accès requises sous jetons d’accès personnels: repo, admin:repo_hook, read:useret user:email.

• Si le dépôt se trouve dans le compte GitHub personnel d’une autre personne, le mot de passe doit avoir les étendues d’accès requises sous jetons d’accès personnels: repo, admin:repo_hook, read:useret 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 dépôt 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:useret user:email. Vous devez être ajouté en tant que collaborateur, ou votre équipe doit être ajoutée, dans les paramètres du référentiel sous « Collaborateurs et équipes ».

• Si le dépôt se trouve dans une organisation GitHub propriétaire d’une autre personne, le mot de passe doit avoir les étendues d’accès requises sous jetons d’accès personnels: repo, admin:repo_hook, read:useret user:email. Vous devez être ajouté en tant que collaborateur, ou votre équipe doit être ajoutée, 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 autre utilisation, visitez jetons d’accès personnels dans vos paramètres GitHub. Vous pouvez également la 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 balises spécifiées.

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

Branches

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

trigger:
- main
- releases/*

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

Note

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

Note

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

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

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

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

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

En plus de spécifier des noms de branche dans les listes de branches, vous pouvez également configurer des déclencheurs en fonction des balises à l’aide du format suivant :

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

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

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

Important

Lorsque vous spécifiez un déclencheur, il remplace le déclencheur implicite par défaut et uniquement les push vers les branches qui sont explicitement configurées pour être incluses déclenchent un pipeline. Les inclusions sont traitées en premier, puis les exclusions sont supprimées de cette liste.

Exécutions ci par lot

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

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

Note

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

Pour clarifier cet exemple, supposons qu’une A push vers main a provoqué l’exécution du pipeline ci-dessus. Pendant que ce pipeline est en cours d’exécution, des push supplémentaires B et des C se produisent dans le référentiel. Ces mises à jour ne démarrent pas immédiatement de nouvelles exécutions indépendantes. Mais une fois la première exécution terminée, toutes les poussées jusqu’à ce point de temps sont regroupées par lots et une nouvelle exécution est démarrée.

Note

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

Chemins

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

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

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

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

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

Étiquettes

En plus de spécifier des balises dans les listes de 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 d’étiquette, 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 d’étiquette est satisfait. Par exemple, si une balise push 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 est satisfait du 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 de cette branche est évalué pour déterminer si une exécution CI doit être démarrée.

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

Modifications par lot

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

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

Note

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

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

Filtres de branche

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

Filtres de chemin d’accès

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

Conseils :

• Les chemins d’accès sont toujours spécifiés par rapport à la racine du référentiel.
• Si vous ne définissez pas de filtres de chemin d’accès, le dossier racine du dépôt est implicitement inclus par défaut.
• Si vous excluez un chemin d’accès, vous ne pouvez pas également l’inclure, sauf si vous le qualifiez dans un dossier plus approfondi. Par exemple, si vous excluez /tools, vous pouvez inclure /tools/trigger-runs-on-these
• L’ordre des filtres de chemin d’accès n’a pas d’importance.
• Les chemins d’accès dans Git respectent la casse. Veillez à utiliser le même cas que les dossiers réels.

Exemple

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

Ignorer ci pour les validations individuelles

Vous pouvez également indiquer à Azure Pipelines d’ignorer l’exécution d’un pipeline qu’un push déclencherait normalement. Incluez simplement [skip ci] dans le message ou la description de l’une des validations qui font partie d’un push, et Azure Pipelines ignore l’exécution de l’intégration continue pour ce push. Vous pouvez également utiliser l’une des variantes suivantes.

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

Utilisation du type de déclencheur dans les conditions

Il s’agit d’un scénario courant pour exécuter différentes étapes, travaux ou étapes dans votre pipeline en fonction du type de déclencheur qui a démarré l’exécution. Vous pouvez le faire à l’aide de la variable système Build.Reason. Par exemple, ajoutez la condition suivante à votre étape, travail ou étape pour l’exclure des validations de demande de tirage.

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

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

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

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

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

Caractères génériques

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

• Si vous démarrez votre modèle avec * dans un pipeline YAML, vous devez encapsuler le modèle entre guillemets, comme "*-releases".
• Pour les branches et les balises :
  • Un caractère générique peut apparaître n’importe où dans le modèle.
• Pour les chemins d’accès :
  • Dans Azure DevOps Server 2022 et versions ultérieures, notamment Azure DevOps Services, un caractère générique peut apparaître n’importe où dans un modèle de chemin et vous pouvez utiliser * ou ?.
  • Dans Azure DevOps Server 2020 et inférieur, vous pouvez inclure * comme caractère final, mais il ne fait rien de différent de spécifier le nom du répertoire lui-même. Vous pouvez pas inclure * au milieu d’un filtre de chemin d’accès, et vous n’utilisez peut-être pas ?.

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

Déclencheurs de demande de tirage

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

Branches

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

pr:
- main
- releases/*

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

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

Note

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

Note

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

GitHub crée une nouvelle ref lors de la création d’une demande de tirage. 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 ref pointe. Cela signifie que le fichier YAML utilisé pour exécuter le pipeline est également une fusion entre la 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 pr déclencheurs n’apparaît dans votre fichier YAML, les validations de demande de tirage sont automatiquement activées pour toutes les branches, comme si vous avez écrit le déclencheur pr suivant. Cette configuration déclenche une génération quand une demande de tirage est créée et lorsque les validations entrent dans la branche source de toute demande de tirage active.

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

Important

Lorsque vous spécifiez un déclencheur pr 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 illustré dans l’exemple suivant. Dans cet exemple, les demandes de tirage sont validées que les main cibles ou releases/* et que 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 de fichier à 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 état Post neutral sur GitHub lorsqu’une build est ignorée.
• Les caractères génériques sont désormais pris en charge avec les filtres de chemin.
• Les chemins d’accès sont toujours spécifiés par rapport à la racine du référentiel.
• Si vous ne définissez pas de filtres de chemin d’accès, le dossier racine du dépôt est implicitement inclus par défaut.
• Si vous excluez un chemin d’accès, vous ne pouvez pas également l’inclure, sauf si vous le qualifiez dans un dossier plus approfondi. Par exemple, si vous excluez /tools, vous pouvez inclure /tools/trigger-runs-on-these
• L’ordre des filtres de chemin d’accès n’a pas d’importance.
• Les chemins d’accès dans Git respectent la casse. Veillez à utiliser le même cas que les dossiers réels.
• Vous ne pouvez pas utiliser variables dans les chemins, car les variables sont évaluées au moment de l’exécution (une fois le déclencheur déclenché).
• 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 tirage multiples

Vous pouvez spécifier si d’autres mises à jour d’une demande de tirage doivent annuler les exécutions de validation en cours pour la même demande de tirage. La valeur par défaut est true.

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

Validation brouillon de demande de tirage

Par défaut, les déclencheurs de demande de tirage se déclenchent sur les demandes de tirage brouillon et les demandes de tirage prêtes à être examinées. Pour désactiver les déclencheurs de demande de tirage pour les demandes de tirage provisoires, 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 lede schéma YAML .

Note

Si votre déclencheur de pr n’est pas déclenché, suivez les étapes de résolution des problèmes dans la FAQ.

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

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

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), quel que soit l’existence de validations push dont les messages ou descriptions contiennent [skip ci] (ou l’une de ses variantes).
• Les pipelines déclenchés par des modifications apportées à la branche source de la demande de tirage, s’il n’existe aucun validations envoyées (push) dont les messages ou descriptions contiennent [skip ci] (ou l’une de ses variantes). Si au moins une validation push 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 (push) 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 une 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’une build de validation réussisse.

Pour configurer les builds de validation obligatoire pour un dépôt 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 la configuration 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 Status check.

   

Important

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

• Vous utilisez d’authentification d’application GitHub
• Votre pipeline s’exécute au moins une fois dans la semaine dernière

Contributions provenant de sources externes

Si votre dépôt 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 de test de votre pipeline sans vous connecter. Lorsque les utilisateurs en dehors de votre organisation fork 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
• Valider les contributions des forks
• considérations importantes en matière de sécurité

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 des demandes de tirage (pull request) des duplications. Consultez Valider les contributions des forks.
• 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 fourche

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 fourche de votre référentiel. Vous pouvez modifier ce comportement, en tenant compte soigneusement 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 et 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 la case à cocher Générer des demandes de tirage à partir de forks de ce référentiel case à cocher.

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 (pull request) de fourks. Ces secrets sont activés par défaut avec les pipelines GitHub Enterprise Server. Les secrets sont les suivants :

• Jeton de sécurité avec accès à votre dépôt GitHub.
• Ces éléments, si votre pipeline les utilise :
  • informations d’identification de connexion service
  • Fichiers de la bibliothèque de fichiers sécurisés
  • Générer des variables marquées secret

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

Note

Lorsque vous activez les builds de duplication 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 fork les mêmes autorisations que les builds régulières, activez les builds Make fork ont les mêmes autorisations que les builds standard paramètre.

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

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 fourkés à l’aide de la Limiter les demandes de tirage de génération à partir de référentiels GitHub forkés contrôle. 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
• Générer en toute sécurité des demandes de tirage à partir de référentiels dupliqués
• Personnaliser des règles pour générer des demandes de tirage à partir de référentiels dupliqué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 forked. Pour les nouveaux projets et les organisations, la valeur par défaut de la Limiter les demandes de tirage de génération à partir de référentiels GitHub dupliqués paramètre est Désactiver la génération de demandes de tirage à partir de référentiels dupliqués.

Lorsque vous choisissez l’option générer en toute sécurité des demandes d’extraction à partir de référentiels fourkés option, tous les pipelines, l’organisation ou le projet, ne peuvent pas rendre les secrets disponibles pour les builds de PR à partir de référentiels fourchements, ne peuvent pas faire en sorte que ces builds aient les mêmes autorisations que les builds normales et doivent être déclenchées 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 du pipeline. Par exemple, vous pouvez vous assurer que tous les pipelines nécessitent un commentaire pour générer une demande de tirage à partir d’un dépôt GitHub forked, lorsque la demande de tirage appartient à des membres non-équipes 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 à les générer en toute sécurité, ou 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, les nouvelles organisations ont générer en toute sécurité des demandes de tirage à partir de référentiels forkés activées par défaut.

Considérations importantes relatives à la sécurité

Un utilisateur GitHub peut forkr votre dépôt, le modifier et créer une demande de tirage (pull request) 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ée. 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 les Rendre les secrets disponibles pour les builds de fourche case à cocher si votre référentiel est public ou que les utilisateurs non approuvés peuvent envoyer des demandes de tirage qui déclenchent automatiquement des builds. Cette option est désactivée par défaut.

• Compromettre l’ordinateur exécutant l’agent 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 machines d’agent hébergées par Microsoft sont immédiatement supprimées une fois qu’elles ont terminé une build. Il n’y a donc aucun impact durable s’ils sont compromis.

  • Si vous devez utiliser un agent auto-hébergé , ne stockez pas de secrets ni exécutez d’autres builds et versions qui utilisent des secrets sur le même agent, sauf si votre dépôt est privé et que vous approuvez les créateurs de demandes de tirage.

Déclencheurs de commentaire

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 à partir d’utilisateurs inconnus jusqu’à ce que leurs modifications puissent être examinées. Vous souhaitez qu’un de vos membres de l’équipe examine d’abord leur code, puis exécutez le pipeline. Il s’agit généralement d’une mesure de sécurité lors de la génération de code fourni à partir de référentiels fourche.
• 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 Autres actions, Déclencheurs. Ensuite, sous validation de demande de tirage (pull request), 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 la génération 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 des membres non de l’équipe pour exiger le commentaire d’un membre de l’équipe uniquement lorsqu’une demande de tirage est effectuée par un membre non-é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 une génération.

Avec ces deux modifications, la génération de validation des demandes de tirage ne sera pas déclenchée automatiquement, sauf si uniquement sur les demandes de tirage à partir de membres non de l’équipe est sélectionnée et 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 la génération en commentant sur la demande de tirage avec /AzurePipelines run ou /AzurePipelines run <pipeline-name>.

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

Commander	Résultat
/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.

Note

Pour des raisons de 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 du référentiel. Les pipelines ne peuvent pas voir les membres de l’organisation privée, sauf s’ils sont des collaborateurs directs ou appartiennent à une équipe qui est un collaborateur direct. Vous pouvez modifier l’appartenance à votre organisation GitHub de privé à public ici (remplacez Your-Organization par le nom de votre organisation) : https://github.com/orgs/Your-Organization/people.

Exécutions d’informations

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

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

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

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

En savoir plus sur exécutions d’informations.

Caisse

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

Note

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 l’extraction intégrée par checkout: none, puis utiliser une tâche de script pour effectuer votre propre extraction.

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 est toujours true sur les agents non-Windows.

Chemin d’accès à l’extraction

Si vous extrayez un référentiel unique, par défaut, votre code source est extrait dans un répertoire appelé s. Pour les pipelines YAML, vous pouvez le modifier en spécifiant checkout avec un 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 de checkout et que vous extrayez plusieurs référentiels et que vous ne spécifiez pas explicitement le dossier à l’aide de path, chaque référentiel est placé dans un sous-dossier de s nommé après le référentiel. Par exemple, si vous consultez 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 d’annuaire au-dessus de $(Agent.BuildDirectory). Par conséquent, path\..\anotherpath entraîne un chemin d’extraction valide (c’est-à-dire C:\agent\_work\1\anotherpath), mais une valeur comme ..\invalidpath ne sera pas (c’est-à-dire C:\agent\_work\invalidpath).

Vous pouvez configurer le paramètre path dans l’étape de paiement 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

Ce paramètre n’est pas configurable dans l’éditeur classique. Votre code source est extrait dans un répertoire appelé s, qui est relatif à $(Agent.BuildDirectory). Par exemple : si $(Agent.BuildDirectory) est C:\agent\_work\1, le code source est extrait dans C:\agent\_work\1\mycustompath.

Sous-modules

Vous pouvez configurer le paramètre de submodules à l’étape Checkout 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

Vous pouvez configurer le paramètre sous-modules à partir des propriétés de la tâche Obtenir des sources dans votre pipeline si vous souhaitez télécharger des fichiers à partir de sous-modules.

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

• non authentifié : un référentiel public, non authentifié sans informations d’identification requises pour cloner ou extraire.

• authentifié :

  • Contenu dans le même projet que le dépôt 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 par rapport 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 dépôt (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 dépôt dans le deuxième projet en accordant explicitement l’accès au compte de service de génération de projet dans le deuxième projet ou (b) à l’aide de jetons d’accès délimités à la collecte au lieu de jetons d’étendue de projet pour l’ensemble de l’organisation. Pour plus d’informations sur ces options et leurs implications en matière de sécurité, consultez référentiels Access, artefacts et autres ressources.

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

Alternative à l’utilisation de l’option De sous-modules d’extraction

Dans certains cas, vous ne pouvez pas utiliser les sous-modules Checkout. 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 vos référentiels principaux et sous-référentiels 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 des sous-modules, vous pouvez utiliser plutôt une étape de script personnalisée pour extraire des sous-modules. Tout d’abord, obtenez un jeton d’accès personnel (PAT) et préfixez-le avec pat:. Ensuite, encodez en base64 cette chaîne préfixée 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.

Note

Q : Pourquoi ne puis-je pas utiliser un gestionnaire d’informations d’identification Git sur l’agent ?R : Stockage des informations d’identification de 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’informations d’identification peut vous inviter à entrer à nouveau les informations d’identification chaque fois que le sous-module est mis à jour. Cela n’est pas souhaitable pendant les builds automatisées lorsque l’interaction utilisateur n’est pas possible.

Balises de synchronisation

Important

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

L’étape d’extraction utilise l’option --tags lors de l’extraction du contenu d’un dépôt Git. Cela entraîne l’extraction de toutes les balises ainsi que 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 un certain nombre de balises. En outre, l’étape d’extraction synchronise les balises même lorsque vous activez l’option d’extraction superficielle, ce qui peut vaincre son objectif. Pour réduire la quantité de données extraites ou extraites d’un référentiel Git, Microsoft a ajouté une nouvelle option pour contrôler le comportement des balises de synchronisation. Cette option est disponible à la fois dans les pipelines CLASSIQUES et YAML.

Indique si vous souhaitez synchroniser des balises lors de la vérification d’un référentiel dans YAML en définissant la propriété fetchTags et dans l’interface utilisateur en configurant les balises de synchronisation paramètre.

Vous pouvez configurer le paramètre fetchTags dans l’étape de paiement 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 du pipeline.

1. Modifiez votre pipeline YAML et choisissez Autres actions, Déclencheurs.

   

2. Choisissez YAML, Obtenir des sources.

   

3. Configurez le paramètre des balises de synchronisation .

   

Note

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

Vous pouvez configurer les étiquettes de synchronisation paramètre à partir des propriétés de l'Obtenir des sources tâche dans votre pipeline.

Comportement par défaut

• Pour les pipelines existants créés avant la publication de sprint Azure DevOps 209, publié en septembre 2022, la valeur par défaut pour la synchronisation des balises reste identique au comportement existant avant l’ajout des étiquettes de synchronisation options de synchronisation, qui est .
• 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.

Note

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

Extraction superficielle

Vous souhaiterez peut-être limiter la distance à télécharger dans l’historique. Cela aboutit effectivement à git fetch --depth=n. Si votre référentiel est volumineux, cette option peut rendre votre pipeline de build plus efficace. Votre référentiel peut être volumineux s’il a été utilisé depuis longtemps et a un historique dimensionnable. Il peut également être volumineux si vous avez ajouté et supprimé des fichiers volumineux ultérieurement.

Important

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

Vous pouvez configurer le paramètre fetchDepth dans l’étape de paiement 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 Autres actions, Déclencheurs.

   

2. Choisissez YAML, Obtenir des sources.

   

3. Configurez le paramètre de de récupération peu profonde . Décochez extraction superficielle pour désactiver la récupération superficielle, ou cochez la case et entrez une profondeur pour activer la récupération superficielle.

   

Note

Si vous définissez explicitement fetchDepth dans votre étape de checkout, ce paramètre prend la priorité sur le paramètre configuré dans l’interface utilisateur des paramètres de pipeline. Le paramètre fetchDepth: 0 récupère l’historique et remplace le paramètre fetch shallow.

Vous pouvez configurer le paramètre de de récupération peu profonde à partir des propriétés de l'Obtenir des sources tâche dans votre pipeline.

Dans ces cas, cette option peut vous aider à conserver les ressources réseau et de stockage. Il peut également gagner du temps. La raison pour laquelle il ne gagne 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.

Note

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 lorsque l’agent effectue l’extraction. Si la branche est mise à jour rapidement et que vous définissez une valeur très petite pour la récupération superficielle, la validation peut ne pas exister lorsque l’agent tente de l’extraire. Si cela se produit, augmentez le paramètre de profondeur de récupération superficielle.

Ne synchronisez pas les sources

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

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

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

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

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

Sélectionnez le Ne synchronisez pas les sources paramètre dans les propriétés de la tâche Obtenir des sources dans votre pipeline.

Note

Lorsque vous utilisez cette option, l’agent ignore également l’exécution de commandes Git qui nettoient le dépôt.

Nettoyer la build

Vous pouvez effectuer différentes formes de nettoyage du répertoire de travail de votre agent auto-hébergé avant l’exécution d’une 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 ci-dessous.

Note

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 dans l’étape de paiement 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

Lorsque clean est défini sur true le pipeline de génération effectue une annulation des modifications apportées à $(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 job.

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.

• génère: même opération que le paramètre propre décrit dans la tâche d’extraction précédente, ainsi que : Supprime et recrée $(Build.BinariesDirectory). Notez que les $(Build.ArtifactStagingDirectory) et les $(Common.TestResultsDirectory) sont toujours supprimés et recréés avant chaque build, quel que soit l’un de ces paramètres.

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

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

Sélectionnez le paramètre Nettoyer dans les propriétés de l'Obtenir des sources tâche dans votre pipeline, puis sélectionnez l’une des options suivantes.

• sources: le pipeline de build effectue une annulation des modifications apportées à $(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
  

• Répertoire de sortie et sources: même opération que 'option Sources ci-dessus, plus : Supprime et recrée $(Build.BinariesDirectory). Notez que les $(Build.ArtifactStagingDirectory) et les $(Common.TestResultsDirectory) sont toujours supprimés et recréés avant chaque build, quel que soit l’un de ces paramètres.

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

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

Sources d’étiquettes

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 toutes les builds ou uniquement pour les builds réussies.

Vous ne pouvez 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 déclencheurs dans le menu de l’éditeur YAML.

Dans l’éditeur classique, choisissez YAML, choisissez l'Obtenir des sources tâche, puis configurez les propriétés souhaitées.

Vous pouvez configurer le paramètre Sources d’étiquettes à partir des propriétés de la tâche Obtenir des sources dans votre pipeline.

Dans le format 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. My.Variable pouvez être défini par vous sous l’onglet variables .

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

Certaines variables de build peuvent générer une valeur qui n’est pas une étiquette valide. Par exemple, les variables telles que $(Build.RequestedFor) et $(Build.DefinitionName) peuvent contenir des espaces blancs. Si la valeur contient un espace blanc, la balise n’est pas créée.

Une fois les sources marqué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 donne à 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é. La balise est considérée comme un artefact de build, car elle est produite par la build. Lorsque la build est supprimée manuellement ou par le biais d’une stratégie de rétention, la balise est également supprimée.

Variables prédéfinies

Lorsque vous générez un dépôt 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 GitHub Apps.

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

• Pour les demandes de tirage, elles sont affichées sous l’onglet Conversations de demande de tirage.
• Pour les validations individuelles, elles sont affichées 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 PAT ou connexions OAuth GitHub, 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 d’Azure Pipelines 'application GitHub, l’état est publié sous la forme de Vérifications GitHub. GitHub Checks permet d’envoyer des informations détaillées sur l’état et le test du pipeline, la couverture du code et les erreurs. L’API GitHub Checks 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, réexécuter toutes les vérifications ayant échoué sur cette demande/validation, ou réexécuter toutes les vérifications, qu’elles réussissent initialement ou non.

Si vous cliquez sur le lien « Réexécuter » en regard du nom Vérifier l’exécution, Azure Pipelines réessaye l’exécution qui a généré la 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 la build initiale. Seuls les travaux qui ont échoué dans l’exécution initiale et tous les travaux en aval dépendants seront réexécuter. 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.

Limitations

• Pour des performances optimales, nous recommandons un maximum de 50 pipelines dans un seul référentiel. Pour des performances acceptables, nous recommandons un maximum de 100 pipelines dans un seul référentiel. Le temps nécessaire pour traiter un envoi (push) vers un référentiel augmente avec le nombre de pipelines de ce référentiel. Chaque fois qu’il y a un push 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’eux doit s’exécuter et charger 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 étend et inclure des modèles dans un pipeline impacte 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 au maximum 2000 branches à partir d’un référentiel dans des listes déroulantes dans le portail Azure DevOps, par exemple dans la fenêtre Sélectionner une branche pour la branche par défaut branche par défaut pour les builds manuelles et planifiées paramètre, ou lorsque vous choisissez une branche lors de l’exécution manuelle d’un pipeline.

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

  Si vous cliquez sur les points de suspension et ouvrez le dialogue Sélectionner une branche et fermez-la sans choisir une branche valide dans la liste déroulante, vous pouvez voir une Certains paramètres ont besoin d’attention message et un Ce paramètre est requis message ci-dessous Branche par défaut pour les builds manuelles et planifiées. Pour contourner ce message, rouvrez le pipeline et entrez le nom directement dans la branche par défaut pour les builds manuelles et planifiées champ.

FAQ

Les problèmes liés à l’intégration de GitHub se trouvent dans les 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 dépôt.
• Échec de l’extraction: Mon pipeline est déclenché, mais il échoue à l’étape d’extraction.
• 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 rendu compte d’une mise à jour d’état.

Types de connexion

Pour résoudre les problèmes de déclencheurs, comment savoir le type de connexion GitHub que 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 d’Azure Pipelines.

• À partir de GitHub : si un dépôt est configuré pour utiliser l’application GitHub, les états sur les demandes de tirage et les validations sont Les exécutions de vérification. Si le dépôt 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 dépôt utilise l’application.
  • Si le lien « Détails » redirige vers le pipeline Azure DevOps, l’état est un état « ancien style » et le dépôt 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. Sélectionnez ensuite 'onglet YAML, puis Obtenir des sources étape. 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é :

  • '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 dépôt.
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 à partir de votre organisation GitHub et recommencer.
3. Dans la page suivante qui s’affiche, vous n’avez pas besoin de continuer à créer 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 « Obtenir des sources » 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 dépôt GitHub pour vérifier qu’une build est correctement mise en file d’attente dans sa section « Vérifications ».

Pourquoi un dépôt GitHub ne s’affiche-t-il pas pour moi pour choisir dans Azure Pipelines ?

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

• Si vous utilisez l’application GitHub, consultez 'authentification GitHub App.
• Si vous utilisez OAuth, consultez l’authentification OAuth.
• Si vous utilisez des PAT, consultez 'authentification par jeton d’accès personnel (PAT).

Lorsque je sélectionne un référentiel lors de la création du pipeline, j’obtiens une erreur « Le dépôt {repo-name} 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 continuer à créer un pipeline.

1. Ouvrez une demande de tirage (pull request) dans votre dépôt GitHub et effectuez le commentaire /azp where. Cela signale à 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 l’organisation appropriée 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 vos déclencheurs défaillants :

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

  

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

  

• 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 dépôt GitHub et effectuez le commentaire /azp where. Cela signale à 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, une personne a déjà établi un pipeline pour ce dépôt dans une autre organisation. Nous avons actuellement la limitation que nous ne pouvons mapper qu’un dépôt 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 l’organisation appropriée 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 aux 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 dépôt et le fichier YAML. Si vous disposez d’un dépôt 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 du traitement par lots ou des filtres de branche plus stricts.

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

• Avez-vous mis à jour le fichier YAML dans la branche correcte ? Si vous envoyez une mise à jour à une branche, le fichier YAML de cette même branche régit le comportement CI. Si vous envoyez une mise à jour à une branche source, le fichier YAML résultant de la fusion de la branche source avec la branche cible régit le comportement de demande de tirage. Vérifiez que le fichier YAML dans la branche correcte a la configuration CI ou PR nécessaire.

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

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

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

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

• Avez-vous juste poussé une nouvelle branche ? Si c’est le cas, la nouvelle branche peut ne pas démarrer une nouvelle exécution. Consultez la section « Comportement des déclencheurs lors de la création de nouvelles branches ».

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

Tout d’abord, 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 demande de tirage qui n’a pas déclenché de pipeline, ouvrez-la et vérifiez si elle a un conflit de fusion. Résolvez le conflit de fusion.

• Rencontrez-vous un retard dans le traitement des événements Push ou PR ? Vous pouvez généralement vérifier un délai en voyant si le problème est spécifique à un seul pipeline ou est commun à tous les pipelines ou dépôts de votre projet. Si une mise à jour push ou pr vers l’un des dépôts présente ce symptôme, nous pouvons rencontrer des retards dans le traitement des événements de mise à jour. Voici quelques raisons pour lesquelles un délai peut se produire :

  • Nous rencontrons une panne de service sur notre page d’état . Si la page d’état affiche un problème, notre équipe doit déjà commencer à travailler dessus. Consultez fréquemment la page pour connaître les mises à jour sur le problème.
  • Votre référentiel contient trop de pipelines YAML. Pour des performances optimales, nous recommandons un maximum de 50 pipelines dans un seul référentiel. Pour des performances acceptables, nous recommandons un maximum de 100 pipelines dans un seul référentiel. Plus il y a de pipelines, plus le traitement d’un push vers ce référentiel est lent. Chaque fois qu’il y a un push 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’eux doit s’exécuter, et chaque nouveau 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 puis-je le faire ?

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

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

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

Échec de l’extraction

L’erreur suivante s’affiche dans le fichier journal lors de l’étape d’extraction. Comment puis-je le 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 incorrecte

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

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

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é de communiquer avec GitHub dans Azure DevOps. 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.

Articles connexes

• déclencheurs planifiés
• déclencheurs d’achèvement du pipeline