Monitoring GitHub Actions

GitHub Actions est devenu la solution CI/CD de référence pour des millions de développeurs. Intégrée nativement à GitHub, elle permet d'automatiser les builds, tests, déploiements et bien plus encore. Cependant, la surveillance de ces workflows automatisés présente des défis uniques que les notifications GitHub natives ne couvrent pas entièrement.

Un problème majeur concerne les workflows planifiés (schedule) : GitHub désactive automatiquement les schedules sur les repositories inactifs depuis plus de 60 jours. Vos backups quotidiens, synchronisations, ou tâches de maintenance peuvent s'arrêter silencieusement sans aucune notification. Les échecs partiels dans les matrices de jobs sont aussi difficiles à suivre.

MoniTao complète GitHub Actions en ajoutant une couche de monitoring heartbeat externe. En intégrant un simple step curl dans vos workflows, vous êtes alerté instantanément si un workflow planifié ne s'exécute pas ou échoue, indépendamment des notifications GitHub.

Types de déclencheurs GitHub Actions

GitHub Actions offre de nombreux types de déclencheurs. Le monitoring heartbeat est particulièrement utile pour les workflows planifiés.

• schedule : exécution selon une syntaxe cron (UTC). Idéal pour backups, syncs quotidiennes, nettoyages. C'est ce type qui nécessite le plus de surveillance externe.
• push/pull_request : déclenchement sur événement Git. La surveillance heartbeat est moins pertinente car il y a toujours une activité humaine associée.
• workflow_dispatch : déclenchement manuel depuis l'interface GitHub. Utile pour les tâches à la demande.
• repository_dispatch : déclenchement par webhook externe. Permet de lier GitHub Actions à d'autres systèmes.

Défis spécifiques à GitHub Actions

Les workflows GitHub Actions présentent des défis de surveillance uniques.

• Désactivation automatique : GitHub désactive les schedules sur les repos inactifs depuis 60 jours. Vos crons critiques peuvent s'arrêter sans aucune alerte.
• Échecs partiels (matrix) : dans une matrix de jobs, certains peuvent échouer tandis que d'autres réussissent. Difficile à suivre sans monitoring dédié.
• Concurrency limits : un workflow peut être en attente indéfiniment si les limites de concurrence sont atteintes.
• Secrets expirés : un secret manquant ou expiré peut faire échouer silencieusement un workflow qui fonctionnait avant.

Stratégies d'intégration heartbeat

Plusieurs approches permettent d'intégrer le monitoring MoniTao dans vos workflows GitHub Actions.

• Step curl final : ajoutez un step curl en fin de job avec if: success(). Simple et efficace pour la plupart des cas d'usage.
• Action HTTP personnalisée : utilisez une action comme fjogeleit/http-request-action pour plus de flexibilité (headers, body, etc.).
• Job dédié : créez un job final avec needs: [job1, job2, ...] qui ne s'exécute que si tous les jobs précédents réussissent.
• Secret pour l'URL : stockez l'URL MoniTao en secret pour éviter de l'exposer dans le code du workflow.

Exemple de workflow avec heartbeat

Voici un exemple complet de workflow GitHub Actions avec monitoring heartbeat intégré :

name: Daily Backup
on:
  schedule:
    - cron: "0 2 * * *"  # 2h00 UTC chaque jour
  workflow_dispatch:     # Déclenchement manuel possible

jobs:
  backup:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run backup script
        run: ./scripts/backup.sh
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}

      - name: Notify MoniTao success
        if: success()
        run: curl -fsS "${{ secrets.MONITAO_URL }}"

      - name: Notify MoniTao failure
        if: failure()
        run: curl -fsS "${{ secrets.MONITAO_URL }}/fail?msg=Backup+failed"

Le secret MONITAO_URL contient votre URL de ping. Le step "success" est exécuté uniquement si le backup réussit. Le step "failure" notifie explicitement les échecs avec un message.

Configuration des alertes

Configurez vos alertes MoniTao pour couvrir les différents scénarios d'échec GitHub Actions.

• Workflow non déclenché : aucun ping reçu à l'heure prévue. Peut indiquer un schedule désactivé ou un repo devenu inactif.
• Échec explicite : le workflow a envoyé un ping /fail. Consultez les logs du workflow sur GitHub pour identifier la cause.
• Durée excessive : le workflow prend plus de temps que d'habitude. Peut indiquer un problème de ressources ou une régression.
• Échecs répétés : plusieurs exécutions consécutives ont échoué. Investigation urgente requise.

Questions fréquentes sur GitHub Actions

Conclusion

GitHub Actions est un outil puissant pour l'automatisation, mais ses workflows planifiés nécessitent une surveillance externe. La désactivation automatique des schedules sur les repos inactifs peut avoir des conséquences critiques si vos backups ou syncs s'arrêtent silencieusement.

En combinant GitHub Actions avec le monitoring heartbeat de MoniTao, vous obtenez une visibilité complète sur vos workflows automatisés. Commencez par vos workflows schedule critiques et maintenez votre repository actif pour éviter la désactivation.

Prêt à dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.

Créer mon compte Voir les tarifs