Automatiser avec GitHub

Automatiser avec GitHub vous permet de créer des règles qui réagissent à l'activité de vos dépôts et agissent en retour sur GitHub — sans script requis. C'est fait pour quiconque souhaite que les incidents, déploiements et événements d'infrastructure restent synchronisés avec son workflow 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.
• Faites agir InfraNest en retour sur GitHub : ouvrir des issues, fusionner des pull requests, déclencher des workflows, définir des statuts de commit, et plus encore.
• Utilisez des automatisations prêtes à l'emploi pour connecter GitHub aux incidents, aux certificats, aux domaines et à votre page de statut en quelques clics.

NoteLes déclencheurs GitHub nécessitent que l'app InfraNest Automations soit installée. Une connexion établie avec un simple jeton ne peut exécuter que des actions GitHub — elle ne peut pas démarrer une règle à partir de l'activité GitHub.

#Connectez GitHub avant de commencer

1. Allez dans Intégrations et connectez votre compte GitHub (voir Connect GitHub).
2. Dans le créateur d'automatisation, les déclencheurs et actions GitHub apparaissent ensemble sous le groupe GitHub.
3. Si vous choisissez un déclencheur GitHub avant de vous connecter, InfraNest vous rappelle 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 une exécution de workflow, une issue, une pull request, un push, une release, un déploiement, ou un check terminé.
2. Ajoutez des filtres Only if pour affiner, comme une branche spécifique, un dépôt, ou uniquement les échecs. Les champs dépôt et compte suggèrent vos dépôts connectés au fur et à mesure que vous tapez.
3. Pour les push, filtrez sur Branch or tag et Deleted si vous ne voulez que les nouveaux commits sur une branche, et non les branches ou tags supprimés.
4. Pour les commentaires, filtrez sur On a pull request si vous ne voulez que les commentaires de pull request, car les commentaires d'issue et de PR arrivent de la même façon.
5. Pour les releases, ajoutez Add “Action equals published” pour que la règle s'exécute une fois par release au lieu de trois fois. Le créateur peut ajouter ce filtre pour vous.
6. Définissez un Cooldown si nécessaire — il s'applique par issue, workflow, commit ou déploiement, et ne retient jamais un autre dépôt.

#Agir sur GitHub (actions)

1. Sous Do this, sélectionnez Add action et choisissez une action GitHub — par exemple Déclencher un workflow GitHub, Créer une issue GitHub, Fusionner la pull request, Créer un déploiement GitHub, Créer une release GitHub, ou Définir le statut du commit.
2. Choisissez quelle connexion GitHub l'action doit utiliser. Si vous n'en avez qu'une, elle est déjà sélectionnée.
3. Remplissez des champs comme le dépôt, le workflow, la branche, l'environnement, les labels ou les assignés — ceux-ci proposent une liste consultable depuis votre GitHub connecté, ou vous pouvez saisir une valeur ou insérer une variable du déclencheur.
4. Si un champ ne parvient pas à charger sa liste, consultez le message en dessous — il vous indiquera s'il faut reconnecter dans Intégrations, réactiver l'app sur GitHub, accorder une permission, ou donner à l'app l'accès à ce dépôt.

#Transformer les incidents et avertissements en issues GitHub

1. Pour ouvrir automatiquement une issue pour chaque incident, allez dans Integrations → GitHub, ouvrez Connections & settings, activez Issues for Incidents, et choisissez le Repository. Résoudre l'incident ferme l'issue ; un incident répété alors que l'issue est encore ouverte ajoute un commentaire au lieu d'en créer une nouvelle.
2. Pour transformer manuellement un incident ou un avertissement en issue, ouvrez son menu ⋯ (ou Create issue sous Follow-up sur la page d'un incident), sélectionnez Create a GitHub issue, choisissez le dépôt, vérifiez What we send, et créez-la. La carte affiche alors l'issue, comme infra#42 · Open.
3. Si une issue existe déjà, sélectionnez Link an existing issue et collez son adresse ou owner/repo#42.
4. Si la boîte de dialogue trouve déjà une issue ouverte correspondante dans le dépôt choisi, elle propose Link that one instead.
5. Si l'issue est fermée mais que le problème n'est pas résolu, utilisez Reopen infra#42 depuis le même menu.

NoteLes dépôts dont les issues sont désactivées, ainsi que les dépôts archivés, ne sont pas proposés, car GitHub refuserait la création de l'issue.

#Démarrer à partir d'une automatisation prête à l'emploi

1. Ouvrez GitHub sous Intégrations et consultez Ready-made automations, ou allez dans Automations → Templates.
2. Sélectionnez Use sur le modèle souhaité.
3. Choisissez le dépôt ou la page de statut qu'il doit utiliser.
4. Sélectionnez Enregistrer l'automatisation.

Parmi les automatisations prêtes à l'emploi utiles :

• Incident opened → open a GitHub issue, associée à Incident resolved → close its GitHub issue, pour que les issues se suivent et se ferment automatiquement.
• Certificate expiring → open a GitHub issue, envoyée deux semaines avant l'expiration.
• Domain expiring → open a GitHub issue, envoyée un mois avant l'expiration.
• Release published → announce on status page, pour les releases complètes uniquement (pas les préversions).
• GitHub workflow failed → re-run failed jobs once, pour qu'un job instable bénéficie d'une seconde chance sans répétitions infinies.
• Deployment succeeded → check it is up → set commit status, qui vérifie l'environnement dès que GitHub signale le déploiement et marque le commit en vert ou en rouge selon le résultat.
• Deployment succeeded → purge the Cloudflare cache Pro, pour que les visiteurs voient immédiatement la nouvelle version.
• Deployment succeeded → announce on status page.
• GitHub workflow failed → open an issue & alert.
• Certificate expiring → run a GitHub workflow.

Les titres et messages de ces modèles sont pré-rédigés avec des variables (comme Released: {{tag}}) remplies automatiquement lors de l'exécution de l'automatisation. Vous pouvez modifier le texte avant d'enregistrer.

TipLes trois automatisations Deployment succeeded n'agissent que sur les déploiements de production, donc les déploiements de prévisualisation (par exemple depuis Vercel) ne déclencheront pas de publications sur la page de statut ni de purges de cache.

#Exemples

• Échec du renouvellement SSL → créer une issue GitHub, lui ajouter le label infrastructure, et l'assigner à votre équipe DevOps.
• Un incident résolu → commenter son issue liée, puis la fermer, en utilisant Linked records pour le numéro d'issue et le dépôt. Si aucune issue n'a été ouverte, l'étape est ignorée.
• Une pull request fusionnée dans main → lancer votre workflow de déploiement, puis définir le statut du déploiement.
• Votre contrôle de santé de production a réussi → définir le statut du commit sur succès.
• Une release a été 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 actions que vos propres automatisations effectuent sur GitHub — un commentaire, un label, un workflow démarré — ne redéclenchent pas vos déclencheurs GitHub, afin qu'une règle ne puisse pas répondre indéfiniment à son propre commentaire.
• Si deux de vos 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 peuvent nécessiter un forfait supérieur — elles affichent un badge Pro dans le créateur.
• Fusionner la pull request ne fusionne que le commit exact vu par la règle ; si quelqu'un pousse un commit après, rien n'est fusionné, et l'exécution explique pourquoi.
• Laissez la branche du workflow vide pour utiliser la branche par défaut du dépôt.
• Retry on transient failure couvre les pannes GitHub, les délais dépassés et les limites de débit ; un véritable refus affiche la raison propre à GitHub dans l'historique d'exécution.
• Si une étape pointe vers une issue censée avoir été créée plus tôt dans la règle et qu'aucune n'a été créée, l'étape est ignorée, et non en échec.