À propos du développement de GitHub Apps pour GitHub Enterprise Server
Si vous souhaitez que votre GitHub App soit disponible pour des organisations dans une instance GitHub Enterprise Server dont vous ne faites pas partie, vous devez suivre les étapes suivantes.
Ces étapes ne sont pas nécessaires si votre GitHub App ne sera utilisé que par des 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, demandez-vous si une action personnalisée pour GitHub Actions ne répondrait pas mieux à vos besoins. Les actions publiques sont disponibles sur les instances GitHub Enterprise Server avec GitHub Connect. Pour plus d’informations, consultez Activation de l’accès automatique aux actions de GitHub.com à l’aide de GitHub Connect.
Chaque instance de GitHub Enterprise Server doit enregistrer son propre GitHub App
Les organisations appartenant à une instance GitHub Enterprise Server ne peuvent pas installer GitHub Apps enregistré sur GitHub.com ou sur une autre instance GitHub Enterprise Server. Au lieu de cela, ils doivent inscrire et installer eux-mêmes GitHub App pour une utilisation sur cette instance.
-
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 ».
-
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. Les mêmes paramètres de manifeste ou d’URL peuvent être partagés avec plusieurs GitHub Enterprise Server instances.
-
Un propriétaire d’organisation dans l’instance utilise les paramètres de manifeste ou d’URL pour inscrire un GitHub App.
-
L’organisation installe le GitHub App qu’elle a enregistré.
Le cas échéant, si l’organisation a rendu le GitHub App public, d’autres organisations dans l’instance peuvent également installer le GitHub App. Il n’est pas possible d’installer un GitHub App sur une instance entière, uniquement sur les organisations au sein d’une instance.
Le code de l’application doit être en mesure d’accéder aux GitHub App informations d’identification de l’instance
Le code de votre application aura besoin des identifiants du GitHub App enregistré par 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 de l’instance, ou avoir l’hôte GitHub Enterprise Server du client et gérer une version auto-hôte de l’application.
Obtenir les informations d’identification de l’instance GitHub Enterprise Server
L’instance peut partager ses GitHub App informations d’identification et son nom d’hôte 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.
Permettre au client GitHub Enterprise Server d’héberger et de 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 Teamet GitHub Enterprise Cloud. Vous devez mettre à jour votre code d’application pour utiliser l’URL appropriée selon qu’elle fonctionne avec une GitHub Enterprise Server instance. 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:/ | https:/ |
https:/ | https:/ |
https:/ | https:/ |
https:/ | https:/ |
Le code de l’application doit avoir connaissance des différences de fonctionnalités
Les nouveaux points de terminaison de l’API REST, les objets GraphQL et les webhooks sont publiés pour GitHub Enterprise Server à une date ultérieure à celle de GitHub Free, GitHub Pro, GitHub Team et GitHub Enterprise Cloud. En outre, il existe plusieurs versions de GitHub Enterprise Server, et les versions plus anciennes peuvent avoir des points de terminaison de l’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 des webhooks incluent un en-tête x-github-enterprise-version pour les charges utiles GitHub Enterprise Server, afin de vous aider à déterminer la version que vous traitez.
Chaque GitHub Enterprise Server instance peut configurer des limites de débit
Chaque GitHub Enterprise Server instance 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 communiquer avec l’administrateur de l’instance GitHub Enterprise Server .