Automatiser avec GitHub

Automatiser avec GitHub vous permet de créer des règles qui réagissent à l’activité de vos dépôts GitHub et d’agir en retour sur GitHub — sans script requis. C’est fait pour toute personne qui gère l’infrastructure ou les workflows d’incidents aux côtés d’une équipe de développement utilisant GitHub.

Vue d’ensemble

• Déclenchez des automatisations à partir d’événements GitHub comme les exécutions de workflow, les issues, les pull requests, les push, les releases et les déploiements
• Agissez automatiquement sur GitHub — créez des issues, fusionnez des pull requests, déclenchez des workflows, définissez le statut d’un commit, et plus encore
• Combinez GitHub avec le reste d’InfraNest, par exemple en ouvrant une issue GitHub dès qu’un incident démarre

Avant de commencer

1. Allez dans Intégrations et connectez votre compte GitHub.
2. Pour utiliser les déclencheurs GitHub (le côté When this happens d’une règle), l’app InfraNest Automations doit être installée — une connexion par jeton ne peut exécuter que des actions GitHub, pas déclencher à partir d’événements GitHub.
3. Dans le générateur d’automatisation, les déclencheurs et actions GitHub apparaissent ensemble sous le groupe GitHub.
4. Si vous choisissez un déclencheur GitHub avant de vous être connecté, InfraNest vous rappellera de vous connecter d’abord.

Réagir à l’activité GitHub (déclencheurs)

1. Démarrez une nouvelle automatisation et, sous When this happens, choisissez un déclencheur GitHub — par exemple Exécution de workflow GitHub, Issue GitHub, Pull request GitHub, Push GitHub, Release GitHub, Déploiement GitHub, Statut de déploiement GitHub, Statut de commit GitHub, ou Check run GitHub.
2. Ajoutez des filtres Only if pour affiner — par exemple uniquement la Branche, uniquement un Dépôt spécifique, uniquement les échecs, ou uniquement votre Organisation. Les champs Dépôt et compte suggèrent vos dépôts et comptes connectés au fur et à mesure que vous tapez.
3. Gardez à l’esprit quelques particularités des filtres :
   • Les événements Push GitHub incluent les tags et les branches supprimées — filtrez sur Branche et Supprimé pour ne réagir qu’aux nouveaux commits.
   • Commentaire GitHub (issue ou PR) se déclenche à la fois pour les issues et les pull requests — filtrez Sur une pull request pour n’en choisir qu’une.
   • Release GitHub se déclenche trois fois par release. Ajoutez Action égal à published pour que votre règle ne s’exécute qu’une fois — le générateur vous proposera de l’ajouter automatiquement.
   • Assignés (tous) correspond à chaque événement d’issue ; Responsable ne correspond qu’à la personne qui vient d’être assignée ou désassignée.
   • Environnement de production permet de distinguer un déploiement de production d’un déploiement de prévisualisation.
   • Tentative compte les relances de workflow — 1 correspond à la première exécution.
   • Temps de recharge s’applique par issue, workflow, commit ou déploiement — un temps de recharge sur un dépôt ne bloque jamais un autre dépôt.

Agir sur GitHub (actions)

1. Sous Do this, sélectionnez Ajouter une action et choisissez une action GitHub, comme Déclencher un workflow GitHub, Relancer un workflow GitHub, Relancer les jobs échoués, Annuler l’exécution GitHub, Créer une issue GitHub, Commenter une issue GitHub, Mettre à jour l’issue GitHub, Fermer une issue GitHub, Rouvrir une issue GitHub, Ajouter des labels, Retirer un label, Assigner une issue GitHub, Fusionner la pull request, Demander une review de PR, Créer un déploiement GitHub, Définir le statut du déploiement, Créer une release GitHub, ou Définir le statut du commit.
2. Choisissez avec quelle connexion GitHub l’action doit s’exécuter. Si vous n’en avez qu’une, elle est choisie automatiquement.
3. Remplissez des champs comme Dépôt (owner/repo), Fichier ou id du workflow, Branche, Environnement, Labels (séparés par des virgules), Assignés (séparés par des virgules) et Relecteurs — ceux-ci proposent une liste consultable depuis votre GitHub connecté, ou vous pouvez saisir une valeur ou insérer une variable issue du déclencheur.
4. Si une liste ne se charge pas, consultez le message sous le champ :
   • La connexion doit être reconnectée — reconnectez-la dans Intégrations.
   • L’app GitHub est suspendue — réactivez-la sur GitHub sous Settings → GitHub Apps → Configure.
   • Elle n’est pas autorisée à lire cette liste — accordez la permission sur GitHub.
   • Elle ne peut pas voir ce dépôt — ajoutez le dépôt à l’accès de l’app sur GitHub, ou utilisez un jeton qui peut y accéder.
   • GitHub n’a pas pu être contacté pour le moment — réessayez dans un instant.

Partir d’une automatisation prête à l’emploi

1. Ouvrez GitHub sous Intégrations et cherchez les Ready-made automations, ou allez dans Automatisations et ouvrez Bibliothèque de modèles.
2. Sélectionnez Utiliser sur un modèle, choisissez le dépôt ou la page de statut avec lequel il doit fonctionner, puis sélectionnez Enregistrer l'automatisation.

Des automatisations prêtes à l’emploi utiles qui relient GitHub au reste de votre configuration :

• Incident ouvert → ouvrir une issue GitHub, associée à Incident résolu → fermer son issue GitHub, pour que les issues se suivent et se ferment automatiquement.
• Certificat expirant → ouvrir une issue GitHub, deux semaines avant.
• Domaine expirant → ouvrir une issue GitHub, un mois avant.
• Release publiée → annoncer sur la page de statut, pour les releases complètes uniquement (les préversions sont ignorées).
• Workflow GitHub échoué → relancer les jobs échoués une fois — un job instable bénéficie d’une seule relance, puis c’est à vous de gérer.
• Déploiement réussi → vérifier qu’il est en ligne → définir le statut du commit — InfraNest vérifie votre environnement juste après que GitHub signale le déploiement et marque le commit en conséquence. Cette vérification n’affecte ni la disponibilité des moniteurs ni les incidents ouverts.
• Déploiement réussi → purger le cache Cloudflare.
• Déploiement réussi → annoncer sur la page de statut.
• Workflow GitHub échoué → ouvrir une issue et alerter, et Certificat expirant → lancer un workflow GitHub.

NoteLes trois automatisations Déploiement réussi n’agissent que sur les déploiements de production, de sorte que les déploiements de prévisualisation ne déclenchent ni annonces ni purges de cache.

Exemples

1. Échec du renouvellement SSL → Créer une issue GitHub, ajouter le label infrastructure, et définir Assignés (séparés par des virgules) sur votre équipe DevOps.
2. Incident résolu → Commenter une issue GitHub, puis Fermer une issue GitHub — en utilisant Éléments liés pour remplir automatiquement le numéro d’issue et le dépôt. Si aucune issue n’a été ouverte pour cet incident, l’étape est ignorée.
3. Pull request GitHub fusionnée dans une branche → Lancer un workflow GitHub, puis Définir le statut du déploiement.
4. Un contrôle de santé en production réussit → Définir le statut du commit sur succès.
5. Release GitHub publiée → Publier une annonce sur la page de statut.

Bon à savoir

• Un déclencheur GitHub ne se déclenche que lorsque GitHub est connecté et que l’app est abonnée à ce type d’événement. Si un déclencheur ne s’exécute jamais, demandez à votre administrateur de vérifier les abonnements aux événements de l’app.
• Les automatisations que vous exécutez ne déclenchent pas à nouveau vos propres déclencheurs GitHub — cela empêche une règle de réagir indéfiniment à ses propres commentaires ou labels.
• Si deux espaces de travail InfraNest connectent le même compte GitHub, les automatisations des deux réagiront à ses événements.
• Lorsqu’une étape crée quelque chose (comme une issue ou un déploiement), les étapes suivantes de la même règle peuvent le réutiliser automatiquement.
• Demander une review à une équipe nécessite une connexion d’organisation, pas une connexion personnelle.
• Certaines actions affichent un badge Pro et nécessitent un plan supérieur.

TipLaissez le champ de branche du workflow vide pour utiliser la branche par défaut du dépôt — elle n’a pas besoin de s’appeler main.

Dépannage

• Fusionner la pull request ne fusionne que ce que la règle a vu. Si quelqu’un pousse de nouveaux commits après l’approbation qui a déclenché la règle, rien n’est fusionné, et l’exécution en explique la raison.
• Réessais : définissez Réessayer en cas d’échec temporaire pour réessayer automatiquement en cas de panne, délai dépassé ou limite de débit GitHub. Un refus permanent affiche la raison propre à GitHub dans Historique.
• Si une étape ultérieure pointe vers une issue censée avoir été créée plus tôt (via Éléments liés) et qu’aucune n’a été créée, cette étape est ignorée plutôt qu’en échec.