Créer votre premier workflow GitHub Actions : guide pas-à-pas

Créer votre premier workflow GitHub Actions (pas-à-pas)

Pour concrétiser la théorie, rien ne vaut la pratique. Cette démonstration vous guide dans la création d’un workflow fonctionnel, à l’image d’un guide pas à pas pour créer un agent IA Telegram, de la création du fichier à la vérification de l’exécution. L’objectif est simple : déclencher un job à chaque push sur votre dépôt et observer le résultat dans l’onglet Actions.

Étape 1 : Créer le fichier de workflow

Tout commence par la création d’un fichier YAML dans un dossier spécifique. Suivez ces étapes directement depuis l’interface web de GitHub :

• Accéder à votre dépôt GitHub ouvrez la page principale du projet.
• Ouvrir « Add file » → « Create new file » ce bouton se situe au-dessus de la liste des fichiers.
• Nommer.github/workflows/github-actions-demo.yml le chemin complet crée automatiquement les dossiers nécessaires.
• Utiliser un modèle préconfiguré suggéré GitHub analyse votre code et propose des modèles adaptés ; pour un dépôt Node.js, des templates de test et de build s’affichent.

Le fichier .github/workflows/github-actions-demo.yml sera le cœur de votre automatisation. Choisir un modèle accélère la suite, mais nous allons maintenant examiner la structure manuelle.

Étape 2 : Définir le workflow YAML

Le fichier YAML est la recette complète de votre automatisation. Voici ses quatre composants essentiels, à écrire dans l’éditeur en ligne :

Le nom (name) identifie votre workflow dans l’onglet Actions ; par exemple, « GitHub Actions démonstration ». L’événement déclencheur (on) définit quand le workflow s’exécute, comme push ou pull_request. Les jobs (jobs) regroupent les tâches à effectuer sur un runner ; chaque job contient des steps qui sont des commandes séquentielles, comme l’installation de dépendances ou l’exécution de tests.

Pour notre exemple, un job nommé build qui utilise un runner ubuntu-latest et exécute une commande simple suffit à illustrer le mécanisme. La syntaxe YAML est sensible à l’indentation : chaque niveau doit être aligné avec des espaces.

Étape 3 : Enregistrer et vérifier l’exécution

Après avoir saisi le contenu, cliquez sur « Commit changes » pour enregistrer le fichier directement sur la branche principale. Ce commit est l’événement qui déclenche immédiatement votre workflow.

Pour observer le résultat, rendez-vous dans l’onglet « Actions » de votre référentiel. Vous y verrez l’exécution en cours, avec un statut qui passe de « queued » à « in progress » puis « success » ou « failure ». Le quota gratuit pour les dépôts privés est de 2000 minutes/mois ; cette exécution n’en consomme qu’une fraction, ce qui vous laisse une large marge pour expérimenter.

Prérequis pour commencer avec GitHub Actions

Avant de vous lancer, assurez-vous de disposer des éléments essentiels suivants. La bonne nouvelle : aucune expérience préalable en CI/CD n’est requise. Vous partez de zéro, et c’est parfaitement normal.

• Compte GitHub gratuit indispensable pour héberger vos dépôts et exécuter vos workflows. Avec ce compte, vous disposez déjà de 2000 minutes/mois d’exécution gratuites pour vos projets privés.
• Bases de Git savoir cloner un dépôt, faire des commits et pousser vos modifications avec push. Ces commandes sont le socle de votre interaction avec GitHub.
• Notions GitHub comprendre ce qu’est un dépôt et une pull request. La documentation officielle « Démarrage rapide pour les dépôts » et « Requêtes de tirage » vous aidera si besoin.
• Ligne de commande une aisance minimale avec le terminal est nécessaire pour initialiser un projet, exécuter des tests et interagir avec Git en local.
• Aucune expérience CI/CD requise les concepts d’intégration et de déploiement continus s’apprennent progressivement grâce à ce tutoriel.

Les 100 minutes de quota gratuit selon le type de runner vous donnent une marge de manœuvre pour expérimenter sans risque financier. L’interface GitHub propose des modèles préconfigurés qui analysent automatiquement votre code et suggèrent des workflows adaptés, ce qui facilite grandement vos premiers pas. Si vous utilisez un dépôt public open source, l’exécution de vos workflows est gratuite et illimitée.

Qu’est-ce que GitHub Actions ? Définition et fonctionnement

GitHub Actions est une plateforme d’intégration et de déploiement continus (CI/CD) nativement intégrée à GitHub, lancée en 2019. Elle permet d’automatiser vos tâches de développement directement depuis votre dépôt : exécution de tests, compilation du code, déploiement vers un serveur, et bien plus encore, en réponse à des événements précis.

Le fonctionnement repose sur des workflows, des fichiers YAML placés dans le dossier .github/workflows/ de votre projet. Ces fichiers décrivent l’automatisation complète, à la différence des systèmes autonomes qui décident et s’adaptent seuls: l’événement déclencheur (comme un push ou une pull request), les tâches à accomplir, et l’environnement d’exécution. La Marketplace GitHub propose des milliers d’actions communautaires prêtes à l’emploi, ce qui vous évite de tout coder de zéro.

Concepts fondamentaux : workflows, jobs, événements et runners

Pour maîtriser GitHub Actions, il faut comprendre quatre piliers qui structurent toute l’automatisation. Ces éléments interagissent ensemble pour transformer un simple dépôt Git en une véritable plateforme CI/CD intégrée, tout comme l’automatisation Make permet de créer des agents IA autonomes, lancée en 2019 et accessible à tous les développeurs, quel que soit leur niveau.

La bonne nouvelle ? Vous n’avez pas besoin de tout mémoriser d’un coup. Concentrez-vous d’abord sur la logique générale : chaque workflow répond à un événement, exécute des jobs sur un runner, et chaque job est composé de steps. Comprendre cette chaîne suffit pour créer des automatisations utiles dès aujourd’hui.

Les workflows, événements et jobs

Un workflow est un fichier YAML placé dans le dossier .github/workflows/ de votre dépôt. Il définit la recette complète de votre automatisation : quand elle se déclenche, ce qu’elle fait, et où elle s’exécute. Ce fichier est versionné comme le reste de votre code, ce qui vous permet de suivre son évolution dans le temps.

Les événements sont les déclencheurs qui lancent le workflow. Les plus courants sont push, pull_request, schedule (planification cron) et le déclenchement manuel via workflow_dispatch. Vous pouvez en combiner plusieurs sur un même workflow pour couvrir différents scénarios.

Les jobs représentent les tâches à accomplir. Chaque job s’exécute sur une machine virtuelle fraîche et contient une série de steps séquentielles. Entre les jobs, vous pouvez définir des dépendances : si un job de test échoue, le job de déploiement ne s’exécutera pas, protégeant ainsi votre production.

Les runners et leurs options d’exécution

Les runners sont les machines qui exécutent vos jobs. Par défaut, GitHub met à disposition des machines virtuelles hébergées avec des systèmes préinstallés (Ubuntu, Windows, macOS). Chaque type de runner possède son propre quota de minutes avec 100 minutes accordées gratuitement selon la configuration choisie, extensibles jusqu’à 2000 minutes/mois pour les dépôts privés avec un compte gratuit.

Pour les projets open source, les minutes sont gratuites et illimitées sur les runners hébergés. Une alternative existe avec les runners self-hosted : installez l’agent sur votre propre machine, et chaque exécution ne consomme aucune minute de votre quota. Cette option convient aux équipes qui ont déjà une infrastructure et souhaitent économiser leurs minutes.

Le choix du runner dépend de vos besoins : rapidité d’exécution, logiciels spécifiques, ou contraintes de sécurité. Les runners hébergés restent la solution la plus simple pour démarrer, tandis que les runners self-hosted offrent une flexibilité accrue pour les projets avancés.

Affichage et analyse des résultats de votre workflow

Une fois votre workflow poussé, rendez-vous sur la page principale de votre référentiel GitHub et ouvrez l’onglet Actions. Dans la barre latérale gauche, vous verrez la liste de vos workflows, comme celui nommé « GitHub Actions démonstration ». Cliquez dessus pour consulter les exécutions récentes et leur statut : succès ou échec.

Chaque exécution correspond à un événement déclencheur (un push, par exemple). En cliquant sur une exécution, vous accédez au détail de chaque job et de chaque étape, avec les journaux d’exécution complets. C’est ici que vous diagnostiquez un échec ou vérifiez que vos commandes de build et de test se déroulent correctement.

Étapes suivantes et bonnes pratiques après votre premier workflow

Une fois votre premier workflow opérationnel, automatisez vos tests, builds et déploiements en ajoutant de nouveaux jobs et steps. La progression logique consiste à maîtriser la syntaxe YAML, les événements déclencheurs et les conditions d’exécution pour orchestrer des pipelines plus complexes.

Adoptez les bonnes pratiques de sécurisation : gérez vos secrets via les variables chiffrées GitHub et vérifiez chaque modification de workflow. Pour approfondir, explorez les modèles de workflow officiels et la documentation dédiée, qui couvrent la parallélisation des jobs et les runners self-hosted une option qui ne consomme aucune minute de votre quota gratuit de 2000 minutes/mois pour les dépôts privés.

Coût et consommation de minutes GitHub Actions

Le modèle de tarification de GitHub Actions repose sur un quota mensuel de 2000 minutes gratuites pour les dépôts privés associés à un compte gratuit. Ce quota couvre largement les besoins d’un développeur débutant qui automatise des tests et des builds sur plusieurs projets personnels.

Comprendre la facturation selon le type de runner

La consommation réelle dépend du runner utilisé. GitHub facture les minutes différemment selon la puissance de la machine virtuelle choisie : les runners standard consomment 1 minute de quota par minute d’exécution, tandis que les runners plus puissants (avec plus de RAM et de CPU) multiplient la consommation par un facteur allant de 2 à 10. Le runner le plus courant, ubuntu-latest, reste au tarif de base : 100 minutes de quota correspondent alors à 100 minutes d’exécution réelle.

Suivre sa consommation et éviter les dépassements

Pour surveiller votre utilisation, rendez-vous dans Settings → Billing and plans → Plans and usage. Vous y verrez un histogramme détaillant les minutes consommées par workflow. GitHub permet aussi de configurer des alertes de consommation : vous recevez alors un e-mail lorsque vous atteignez un seuil défini, par exemple 50 % ou 75 % de votre quota mensuel. Une fois le quota épuisé, les workflows s’arrêtent automatiquement pour les dépôts privés aucun frais n’est engagé sans votre accord explicite.

Les projets open source bénéficient d’un traitement particulier : si votre dépôt est public, l’exécution des workflows est gratuite et illimitée. C’est un avantage majeur pour les mainteneurs de bibliothèques ou d’outils communautaires qui peuvent automatiser l’intégration continue sans contrainte budgétaire.