Créer des référentiels du serveur GitHub Enterprise

Article
11/30/2023

Azure DevOps Services

Vous pouvez intégrer votre serveur local GitHub Enterprise local à Azure Pipelines. Votre serveur local peut être exposé à Internet ou non.

Si votre serveur GitHub Enterprise est accessible depuis les serveurs qui exécutent le service Azure Pipelines, alors :

vous pouvez configurer des pipelines de build et YAML classiques
vous pouvez configurer des déclencheurs CI, PR et planifiés

Si votre serveur GitHub Enterprise n’est pas accessible depuis les serveurs qui exécutent le service Azure Pipelines, alors :

vous ne pouvez configurer que des pipelines de build classiques
vous ne pouvez démarrer que des builds manuelles ou planifiées
vous ne pouvez pas configurer de pipelines YAML
vous ne pouvez pas configurer les déclencheurs CI ou PR pour vos pipelines de build classiques

Si votre serveur local est accessible depuis les agents hébergés par Microsoft, vous pouvez les utiliser pour exécuter vos pipelines. Sinon, vous devez configurer des agents autohébergés qui peuvent accéder à votre serveur local et extraire le code.

Accessible depuis Azure Pipelines

La première chose à vérifier est l’accessibilité de votre serveur GitHub Enterprise depuis le service Azure Pipelines.

Dans votre interface utilisateur Azure DevOps, accédez aux paramètres de votre projet, puis sélectionnez Connexions de service sous Pipelines.
Sélectionnez Nouvelle connexion de service et choisissez Serveur GitHub Enterprise comme type de connexion.
Entrez les informations requises pour créer une connexion à votre serveur GitHub Enterprise.
Sélectionnez Vérifier dans le panneau de connexion de service.

Si la vérification réussit, les serveurs qui exécutent le service Azure Pipelines peuvent atteindre votre serveur GitHub Enterprise local. Vous pouvez continuer et configurer la connexion. Vous pouvez ensuite utiliser cette connexion de service lors de la création d’une build classique ou d’un pipeline YAML. Vous pouvez également configurer des déclencheurs CI et PR pour le pipeline. La majorité des fonctionnalités d’Azure Pipelines qui fonctionne avec GitHub fonctionne également avec le serveur GitHub Enterprise. Consultez la documentation de GitHub pour comprendre ces fonctionnalités. Voici quelques différences :

L’intégration entre GitHub et Azure Pipelines est facilitée par une application Azure Pipelines dans la place de marché GitHub. Cette application vous permet de configurer une intégration sans avoir utilisé le jeton OAuth d’un utilisateur particulier. Nous n’avons pas d’application similaire qui fonctionne avec le serveur GitHub Enterprise. Par conséquent, vous devez utiliser un PAT, un nom d’utilisateur et un mot de passe ou OAuth pour configurer la connexion entre Azure Pipelines et le serveur GitHub Enterprise.
Azure Pipelines prend en charge un certain nombre de fonctionnalités de sécurité GitHub pour valider les contributions des fourches externes. Par exemple, les secrets stockés dans un pipeline ne sont pas mis à la disposition d’un travail en cours d’exécution. Ces protections ne sont pas disponibles lorsque le serveur GitHub Enterprise est utilisé.
Les déclencheurs de commentaire ne sont pas disponibles avec le serveur GitHub Enterprise. Vous ne pouvez pas utiliser de commentaires dans une demande de tirage de référentiel de serveur GitHub Enterprise pour déclencher un pipeline.
Les vérifications GitHub ne sont pas disponibles dans le serveur GitHub Enterprise. Toutes les mises à jour d’état sont effectuées via des états de base.

Inaccessible depuis Azure Pipelines

Lorsque la vérification d’une connexion au serveur GitHub Enterprise échoue, comme expliqué dans la section ci-dessus, Azure Pipelines ne peut pas communiquer avec votre serveur. Cela est probablement dû à la configuration de votre réseau d’entreprise. Par exemple, un pare-feu dans votre réseau peut empêcher le trafic externe d’atteindre vos serveurs. Vous avez deux options dans ce cas :

Collaborez avec votre service informatique pour ouvrir un chemin d’accès au réseau entre Azure Pipelines et le serveur GitHub Enterprise. Par exemple, vous pouvez ajouter des exceptions à vos règles de pare-feu pour autoriser le passage du trafic d’Azure Pipelines. Consultez la section sur les adresses IP Azure DevOps pour voir les adresses IP que vous devez autoriser. En outre, vous devez disposer d’une entrée DNS publique pour le serveur GitHub Enterprise afin qu’Azure Pipelines puisse résoudre le nom de domaine complet de votre serveur en adresse IP. Avec toutes ces modifications, essayez de créer et de vérifier une connexion au serveur GitHub Enterprise dans Azure Pipelines.
Au lieu d’utiliser une connexion au serveur GitHub Enterprise, vous pouvez utiliser une autre connexion Git. Veillez à décocher l’option Tentative d’accéder à ce serveur Git depuis Azure Pipelines. Avec ce type de connexion, vous ne pouvez configurer qu’un pipeline de build classique. Les déclencheurs CI et PR ne fonctionnent pas dans cette configuration. Vous ne pouvez démarrer que des exécutions manuelles ou planifiées de pipeline.

Accessible depuis des agents hébergés par Microsoft

Vous serez peut-être amené à prendre une décision quant à l’utilisation d’agents hébergés par Microsoft ou des agents autohébergés pour exécuter vos pipelines. Cela revient souvent à savoir si les agents hébergés par Microsoft peuvent atteindre votre serveur. Pour vérifier s’ils peuvent l’atteindre, créez un pipeline pour utiliser des agents hébergés par Microsoft et veillez à ajouter une étape pour extraire le code source de votre serveur. Si cela réussit, vous pouvez continuer à utiliser des agents hébergés par Microsoft.

Inaccessible depuis les agents hébergés par Microsoft

Si le pipeline de test simple mentionné dans la section ci-dessus échoue avec l’erreur TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting, le serveur GitHub Enterprise n’est pas accessible depuis les agents hébergés par Microsoft. Cela est probablement dû à un pare-feu bloquant le trafic de ces serveurs. Vous avez deux options dans ce cas :

Collaborez avec votre service informatique pour ouvrir un chemin d’accès réseau entre les agents hébergés par Microsoft et le serveur GitHub Enterprise. Consultez la section sur la mise en réseau dans les agents hébergés par Microsoft.
Passez à l’utilisation d’agents autohébergés ou d’agents de groupe identique. Ces agents peuvent être configurés au sein de votre réseau et auront donc accès au serveur GitHub Enterprise. Ces agents nécessitent uniquement des connexions sortantes vers Azure Pipelines. Il n’est pas nécessaire d’ouvrir un pare-feu pour les connexions entrantes. Vérifiez que le nom du serveur que vous avez spécifié lors de la création de la connexion au serveur GitHub Enterprise peut être résolu à partir des agents autohébergés.

Adresses IP Azure DevOps

Azure Pipelines envoie des requêtes au serveur GitHub Enterprise à :

Rechercher une liste de référentiels lors de la création de pipelines (pipelines classiques et YAML)
Rechercher des fichiers YAML existants lors de la création de pipelines (pipelines YAML)
Archiver des fichiers YAML (pipelines YAML)
Inscrire un webhook lors de la création de pipelines (pipelines classiques et YAML)
Présenter un éditeur pour les fichiers YAML (pipelines YAML)
Résoudre les modèles et développer des fichiers YAML avant l’exécution (pipelines YAML)
Vérifier s’il y a des modifications depuis la dernière exécution planifiée (pipelines classiques et YAML)
Récupérer des détails sur la dernière validation et les afficher dans l’interface utilisateur (pipelines classiques et YAML)

Vous pouvez observer que les pipelines YAML nécessitent fondamentalement une communication entre Azure Pipelines et le serveur GitHub Enterprise. Par conséquent, il n’est pas possible de configurer un pipeline YAML si le serveur GitHub Enterprise n’est pas visible par Azure Pipelines.

Lorsque vous utilisez uneautre connexion Git pour configurer un pipeline classique, désactivez la communication entre le service Azure Pipelines et le serveur GitHub Enterprise et utilisez des agents autohébergés pour générer du code, votre expérience ne sera pas optimale :

Vous devrez taper manuellement le nom du référentiel lors de la création du pipeline.
Vous ne pouvez pas utiliser de déclencheurs CI ou PR, car Azure Pipelines ne peut pas inscrire un webhook dans le serveur GitHub Enterprise.
Vous ne pouvez pas utiliser de déclencheurs planifiés avec l’option de génération uniquement lorsqu’il y a des modifications.
Vous ne pouvez pas afficher d’informations sur la dernière validation dans l’interface utilisateur.

Si vous souhaitez configurer des pipelines YAML ou si vous souhaitez améliorer l’expérience avec les pipelines classiques, il est important d’activer la communication entre Azure Pipelines et le serveur GitHub Enterprise.

Pour autoriser le trafic d’Azure DevOps à atteindre votre serveur GitHub Enterprise, ajoutez les adresses IP ou les étiquettes de service spécifiées dans les connexions entrantes à la liste d’autorisation de votre pare-feu. Si vous utilisez ExpressRoute, veillez également à inclure des plages d’adresses IP ExpressRoute à la liste d’autorisation votre pare-feu.

Limites

Pour de meilleures performances, nous recommandons un maximum de 50 pipelines dans un seul dépôt. Pour des performances acceptables, nous recommandons un maximum de 100 pipelines dans un seul dépôt. Le temps nécessaire pour effectuer un envoi (push) vers un référentiel augmente avec le nombre de pipelines de ce dernier. Chaque fois qu’il y a un envoi vers un référentiel, Azure Pipelines doit charger tous les pipelines YAML dans ce référentiel pour déterminer si l’un d’entre eux doit s’exécuter, et le chargement de chaque pipeline entraîne une pénalité de performances. En plus des problèmes de performances, l’utilisation d’un trop grand nombre de pipelines dans un référentiel unique peut entraîner une limitation côté GitHub, car Azure Pipelines peut effectuer trop de requêtes dans un court laps de temps.
L’utilisation de modèles d'extension et d'inclusion dans un pipeline affecte le taux auquel Azure Pipelines effectue des requêtes d’API GitHub et peut entraîner une limitation côté GitHub. Avant d’exécuter un pipeline, Azure Pipelines doit générer le code YAML complet. Il doit donc extraire tous les fichiers de modèle.
Azure Pipelines charge au maximum 2 000 branches à partir d’un référentiel dans des listes déroulantes dans le portail Azure Devops, par exemple dans la branche par défaut pour le paramètre de builds manuelles et planifiées, ou lorsque vous choisissez une branche lors de l’exécution manuelle d’un pipeline. Si vous ne voyez pas votre branche souhaitée dans la liste, tapez son nom manuellement.

FAQ

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

Déclencheurs défaillants : mon pipeline n’est pas déclenché lorsque j’envoie une mise à jour au référentiel.
Échec de la validation : mon pipeline est déclenché, mais il échoue à l’étape de validation.
Version incorrecte : mon pipeline s’exécute, mais il utilise une version inattendue de la source/YAML.

Déclencheurs défaillants

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

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

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

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

Les webhooks sont utilisés pour communiquer les mises à jour de GitHub Enterprise vers Azure Pipelines. Dans GitHub Enterprise, accédez aux paramètres de votre référentiel, puis aux Webhooks. Assurez-vous que les webhooks existent. En règle générale, vous devriez voir deux webhooks : push, pull_request. 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.
Sélectionnez chaque webhook dans GitHub Enterprise 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.
Quand Azure Pipelines reçoit une notification de GitHub, il tente de contacter GitHub et d’extraire plus d’informations sur le référentiel et le fichier YAML. Si le serveur GitHub Enterprise se trouve derrière un pare-feu, ce trafic peut ne pas atteindre votre serveur. Consultez les adresses IP Azure DevOps et vérifiez que vous avez accordé des exceptions à toutes les adresses IP requises. Ces adresses IP peuvent avoir changé depuis que vous avez initialement configuré les règles d’exception.

Votre pipeline est-il suspendu ou désactivé ? Ouvrez l’éditeur du pipeline, puis sélectionnez Paramètres pour vérifier. Si votre pipeline est suspendu ou désactivé, les déclencheurs ne fonctionnent pas.
Avez-vous mis à jour le fichier YAML dans la branche appropriée ? Si vous envoyez une mise à jour vers une branche, le fichier YAML de cette même branche régit le comportement d’intégration continue. Si vous envoyez une mise à jour vers une branche source, le fichier YAML résultant de la fusion de la branche source avec la branche cible régit le comportement de la demande de tirage. Assurez-vous que le fichier YAML dans la branche appropriée a la configuration CI ou PR nécessaire.
Avez-vous correctement configuré le déclencheur ? Lorsque vous définissez un déclencheur YAML, vous pouvez spécifier des clauses include et exclude pour les branches, les étiquettes et les chemins d’accès. Vérifiez que la clause include correspond aux détails de votre validation et que la clause exclude ne les exclut pas. Vérifiez la syntaxe des déclencheurs et assurez-vous qu’elle est exacte.
Avez-vous utilisé des variables pour définir le déclencheur ou les chemins d’accès ? Cela n’est pas pris en charge.
Avez-vous utilisé des modèles pour votre fichier YAML ? Dans ce cas, assurez-vous que vos déclencheurs sont définis dans le fichier YAML principal. Les déclencheurs définis dans les fichiers de modèle ne sont pas pris en charge.
Avez-vous exclu les branches ou chemins vers lesquels vous avez envoyé vos modifications ? Testez en envoyant une modification vers un chemin inclus dans une branche incluse. Notez que les chemins d’accès dans les déclencheurs respectent la casse. Veillez à utiliser la même casse que pour les dossiers réels lors de la spécification des chemins d’accès dans les déclencheurs.
Venez-vous d’envoyer une nouvelle branche ? Dans ce cas, la nouvelle branche peut ne pas démarrer une nouvelle exécution. Consultez la section « Comportement des déclencheurs lors de la création de nouvelles branches ».

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

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

Avez-vous des conflits de fusion dans votre demande de tirage ? Pour une demande de tirage qui n’a pas déclenché de pipeline, ouvrez-la et vérifiez si elle a un conflit de fusion. Résoudre le conflit de fusion.
Rencontrez-vous un retard dans le traitement des événements d’envoi ou de demande de tirage ? Vous pouvez généralement vérifier un délai en regardant si le problème est spécifique à un pipeline unique ou s’il est commun à tous les pipelines ou référentiels de votre projet. Si une mise à jour d’envoi ou de demande de tirage dans l’un des dépôts présente ce symptôme, nous pouvons rencontrer des retards dans le traitement des événements de mise à jour. Voici quelques raisons pour lesquelles un retard peut se produire :
- Nous avons une panne de service dans notre page d’état. Si la page d’état affiche un problème, notre équipe a probablement déjà commencé à travailler dessus. Consultez fréquemment la page pour obtenir des mises à jour sur le problème.
- Votre dépôt contient trop de pipelines YAML. Pour de meilleures performances, nous recommandons un maximum de 50 pipelines dans un seul dépôt. Pour des performances acceptables, nous recommandons un maximum de 100 pipelines dans un seul dépôt. Plus il y a de pipelines, plus le traitement d’un envoi push vers ce dépôt est lent. Chaque fois qu’il y a un envoi push vers un dépôt, Azure Pipelines doit charger tous les pipelines YAML dans ce référentiel pour déterminer si l’un d’eux doit s’exécuter, et chaque nouvelle pipeline entraîne une pénalité de performances.
- Votre instance GitHub Enterprise Server peut être sous-approvisionnée et ralentir de ce fait le traitement des requêtes à partir d’Azure Pipelines. Découvrez plus d’informations sur les considérations matérielles relatives à GitHub Enterprise Server.

Échec de la validation

Utilisez-vous des agents hébergés par Microsoft ? Si oui, ces agents peuvent ne peut-être pas atteindre votre serveur GitHub Enterprise. Pour plus d’informations, consultez Non accessible depuis les agents hébergés par Microsoft.

Version erronée

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

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