Skip to main content

Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-03-26. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Mise à disposition de votre application GitHub pour GitHub Enterprise Server

Pour que les instances GitHub Enterprise Server utilisent votre GitHub App, vous devez effectuer des étapes supplémentaires.

À propos du développement des GitHub Apps pour GitHub Enterprise Server

Si vous souhaitez que votre GitHub App soit disponible pour les organisations dans une instance GitHub Enterprise Server dont vous ne faites pas partie, vous devez effectuer les étapes suivantes.

Ces étapes ne sont pas obligatoires si votre GitHub App est utilisée uniquement par les organisations dans une instance GitHub Enterprise Server dont vous faites partie. Pour plus d’informations, consultez « Installation de votre propre application GitHub ».

Si l’accès à GitHub Enterprise Server est important, déterminez si une action personnalisée pour GitHub Actions répond plutôt à vos besoins. Les actions publiques sont disponibles sur les instances GitHub Enterprise Server avec GitHub Connect. Pour plus d’informations, consultez « Activer l’accès automatique aux actions GitHub.com à l’aide de GitHub Connect. »

Chaque instance GitHub Enterprise Server doit inscrire sa propre GitHub App

Les organisations appartenant à une instance GitHub Enterprise Server ne peuvent pas installer des GitHub Apps inscrites sur GitHub.com ou sur une autre instance GitHub Enterprise Server. Au lieu de cela, elles doivent inscrire et installer leur propre GitHub App pour l’utiliser sur cette instance.

  1. Le développeur de l’application crée un manifeste ou des paramètres d’URL. Pour plus d’informations, consultez « Inscription d’une application GitHub à partir d’un manifeste » et « Inscription d’une application GitHub à l’aide de paramètres d’URL ».

  2. Le développeur de l’application partage le manifeste ou les paramètres d’URL avec l’administrateur GitHub Enterprise Server qui souhaite utiliser l’application. Ce même manifeste ou ces mêmes paramètres d’URL peuvent être partagés avec plusieurs instances GitHub Enterprise Server.

  3. Un propriétaire de l’organisation dans l’instance utilise le manifeste ou les paramètres d’URL pour inscrire une GitHub App.

  4. L’organisation installe l’GitHub App qu’elle a inscrite.

    Si vous le souhaitez, si l’organisation a rendu publique l’GitHub App, d’autres organisations au sein de l’instance peuvent également installer l’GitHub App. Il n’existe aucun moyen d’installer une GitHub App sur une instance entière, uniquement sur les organisations au sein d’une instance.

Le code de l’application doit pouvoir accéder aux informations d’identification de l’GitHub App pour l’instance

Le code de votre application aura besoin des informations d’identification de l’GitHub App qu’a inscrite l’instance GitHub Enterprise Server. Il aura également besoin du nom d’hôte de l’instance. Vous avez deux options : obtenir les informations d’identification et le nom d’hôte auprès de l’instance, ou disposer de l’hôte du client GitHub Enterprise Server et gérer une version auto-hébergeable de l’application.

Obtenir les informations d’identification de l’instance GitHub Enterprise Server

L’instance peut partager ses informations d’identification et son nom d’hôte de l’GitHub App avec le développeur de l’application. L’administrateur du site doit le faire seulement s’il fait confiance au développeur de l’application. Ensuite, le code de l’application peut utiliser les informations d’identification appropriées en fonction des actions qu’il effectue. Le développeur de l’application doit prendre des précautions pour utiliser l’ensemble d’informations d’identification approprié et pour ne pas divulguer les données.

Avantages :

  • Le développeur de l’application contrôle l’infrastructure sur laquelle l’application s’exécute.
  • Le développeur de l’application a un plus grand contrôle sur les mises à jour de l’application.
  • Le développeur de l’application peut avoir plus d’informations sur les performances de l’application.

Inconvénients :

  • Le développeur de l’application doit prendre des précautions pour éviter les fuites des données de l’instance.
  • L’administrateur de site peut avoir besoin d’ouvrir des exceptions de pare-feu pour que votre application atteigne le instance et il peut être réticent à le faire.

Disposer de l’hôte du client GitHub Enterprise Server et gérer une version auto-hébergeable de l’application

Le développeur d’applications peut fournir une version auto-hébergeable de son application. Ensuite, l’administrateur de site peut héberger l’application en fonction des instructions de configuration et d’installation du développeur d’applications.

La méthode par laquelle la version auto-hébergeable de l’application est créée et partagée dépend du développeur de l’application et de la technologie utilisée par l’application.

Avantages :

  • L’instance reste plus sécurisée parce qu’elle ne partage pas ses informations d’identification d’application.
  • Le développeur de l’application n’a pas besoin de se soucier des fuites des données de l’instance.

Inconvénients :

  • Le développeur de l’application s’appuie sur l’administrateur du site pour fournir l’infrastructure de l’application et configurer les choses correctement.
  • La publication de mises à jour du code de l’application peut être plus complexe.
  • Le développeur de l’application peut perdre sa visibilité sur les performances de l’application.

Le code de l’application doit utiliser les URL correctes

GitHub Enterprise Server utilise des URL différentes de GitHub Free, GitHub Pro, GitHub Team et GitHub Enterprise Cloud. Vous devez mettre à jour le code de votre application pour utiliser l’URL appropriée selon qu’elle fonctionne avec une instance GitHub Enterprise Server. Remplacez HOSTNAME par le nom d’hôte de l’instance GitHub Enterprise Server.

GitHub Free
GitHub Pro
GitHub Team
GitHub Enterprise Cloud
GitHub Enterprise Server
https://api.github.comhttps://HOSTNAME/api/v3
https://api.github.com/graphqlhttps://HOSTNAME/api/v3/graphql
https://github.com/login/oauth/authorizehttps://HOSTNAME/login/oauth/authorize
https://github.com/login/oauth/access_tokenhttps://HOSTNAME/login/oauth/access_token

Le code de l’application doit avoir connaissance des différences de fonctionnalités

Les nouveaux points de terminaison d’API REST, objets GraphQL et webhooks sont publiés sur GitHub Enterprise Server à une date ultérieure à GitHub Free, GitHub Pro, GitHub Team et GitHub Enterprise Cloud. De plus, il existe plusieurs versions de GitHub Enterprise Server, et les versions antérieures peuvent avoir des points de terminaison d’API REST, des objets GraphQL et des webhooks différents.

Par conséquent, le code de l’application doit connaître ces différences. Les réponses d’API et les charges utiles de webhook incluent un en-tête x-github-enterprise-version pour les charges utiles GitHub Enterprise Server qui vous aidera à déterminer la version que vous gérez.

Chaque instance GitHub Enterprise Server peut configurer des limites de débit

Chaque instance GitHub Enterprise Server peut configurer ses propres limites de débit. Si votre application atteint une limite de débit et prend déjà des précautions pour rester sous la limite de débit, vous devez en parler à l’administrateur de l’instance GitHub Enterprise Server.