La gestion manuelle des workflows peut être fastidieuse et sujette à des erreurs.
Cela entraîne des retards et une inefficacité dans les processus de développement, impactant la productivité globale.
Grâce à GitHub Actions et ses déclencheurs de workflow, vous pouvez automatiser ces processus, améliorant ainsi la fluidité et l’efficacité de votre développement.
Devenez expert en gestion de dépôts et automatisez avec GitHub Actions!
Déclencheurs Standard GitHub Actions
Dans les sections précédentes, nous avons exploré les déclencheurs de workflow comme le push et la pull request . Cependant, GitHub offre également des filtres pour affiner précisément le déclencheur à surveiller. Par exemple, il est possible de spécifier des types d’actions dans un push ou une pull request , tels que la branche, les chemins ( paths ) ou les types de pull requests .
Voici un exemple :
on:
push:
branches: ['main', 'develop']
paths: ['src/**/*' , 'docs/**/*']
pull_request:
types: [opened, reopened, synchronized]
- push :Le workflow s’exécute uniquement lorsqu’un push est effectué sur les branchesmainoudevelop, et que des fichiers dans les dossierssrcoudocssont modifiés.
- pull_request :Le workflow se déclenche uniquement lors de l’ouverture, de la réouverture, ou de la mise à jour d’une pull request avec de nouveauxcommits.
Planification CRON pour Workflows GitHub
GitHub Actions permet d’automatiser des tâches liées à la gestion des issues et des commentaires. En configurant des déclencheurs pour des actions spécifiques, comme l’ouverture ou la modification d’une issue, ainsi que la création ou l’édition de commentaires, nous pouvons optimiser le suivi des problèmes et améliorer la collaboration.
L’exemple ci-dessous illustre cette configuration.
on:
issues:
types: [opened, edited]
issues_comment:
types: [created, edited]
Ce bloc de configuration définit des déclencheurs pour les issues et les commentaires dans GitHub Actions :
- issues :Le workflow se déclenche lorsqu’une issue est ouverte ou modifiée.
- issues_comment :Le workflow se déclenche lorsqu’un commentaire sur une issue est créé ou modifié.
Déclencheurs Avancés et Intégrations GitHub
La planification des workflows est essentielle pour automatiser les tâches récurrentes à des intervalles réguliers. GitHub Actions permet de programmer des workflows en utilisant des expressions CRON , offrant ainsi une flexibilité pour définir des exécutions automatiques basées sur le temps. Voilà la syntaxe :
on:
schedule:
- cron: '0 0 * * *'
Ce code configure le workflow pour qu’il s’exécute automatiquement selon une planification CRON. L’expression ‘0 0 * * *’ spécifie que le workflow doit être déclenché tous les jours à minuit (00:00 UTC). L’utilisation des expressions CRON permet de définir des horaires d’exécution précisés selon des besoins récurrents.
Réagir aux Événements Externes GitHub
Les déclencheurs avancés et les intégrations permettent de créer des workflows plus sophistiqués et interconnectés. Voici comment utiliser ces fonctionnalités :
- workflow_call :Permet à un workflow d’appeler un autre workflow.
- workflow_run :Déclenche un workflow en réponse à la fin d’un autre workflow.
Exemple de configuration :
on:
workflow_call:
workflow_run:
workflows: ["CI Build"]
types:
- completed
workflow_run : Le workflow est déclenché lorsque le workflow nommé » CI Build » se termine, avec le type d’événement spécifié comme completed .
Pratiquer les Déclencheurs GitHub Actions
Les workflows GitHub peuvent également être déclenchés en réponse à des événements externes via l’API GitHub. Cela permet d’intégrer des processus externes et d’automatiser des actions en fonction de stimuli provenant de l’extérieur de votre dépôt GitHub.
- repository_dispatch :Permet de déclencher un workflow en envoyant une requête API à un dépôt GitHub.
- workflow_dispatch :Permet de déclencher un workflow manuellement à partir de l’interface GitHub ou via une API, avec la possibilité de fournir des entrées spécifiques.
Exemple de configuration :
on:
repository_dispatch:
types: [trigger-action]
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
Explication de l’ exemple :
- repository_dispatch :Le workflow est déclenché lorsqu’une requête API est envoyée au dépôt avec le type d’événement trigger-action.
- workflow_dispatch :Le workflow peut être déclenché manuellement depuis l’interface GitHub ou via l’API, avec un paramètre d’entrée nommé logLevel qui permet de spécifier le niveau de log (par défaut warning).
Déclencheurs CRON GitHub
Dans cette section, nous allons appliquer les déclencheurs de workflow standard que nous avons abordés précédemment.
Pour le faire , nous allons reprendre le worflow sur les scripts nodeJS et personnalier avec nos besoins .Analysons les modifications dans ce fichier maintenant :
name: Node.js Build and Test
on:
push:
pull_request:
types:
- opened
- reopened
branches:
- 'releases/**'
paths:
- '**.js'
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm install
- name: Run build
run: npm run build
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm run test
Voilà, nous avons conservé les deux jobs, build et test, mais nous avons ajouté deux événements à surveiller :
push : Le workflow sera déclenché lorsque du code sera poussé dans le dépôt.
pull_request :
- Le workflow est déclenché à l’ouverture d’une pull request (événements opened et reopened ).
- Cela s’applique uniquement aux branches qui correspondent au motif releases/**.
- Il s’applique aussi uniquement aux fichiers qui correspondent à l’extension .js .
Procédons maintenant au push pour observer le résultat. Nous allons annoter le commit avec le message suivant : Add pull request triggers.
Parfait, on constate que le workflow s’est correctement déclenché et que les jobs se sont exécutés avec succès.
Ce résultat est attendu, car le push ou les pull requests sont les événements spécifiés dans le workflow. Il détecte donc simplement le push, ce qui est logique puisque nous avons configuré cet événement. Maintenant, supprimons l’événement push du workflow et observons ensuite le résultat.
Lançons le commit avec le commentaire : Delete push in workflow
Vérifions dans le repository que seul le script Python s’est exécuté comme montré le visuel ci-dessous, car les conditions pour exécuter le script Nodejs ne sont pas remplies : il n’y a ni pull request ouverte , ni modifications sur les branches releases , ni sur des fichiers .js.
Créons maintenant une branche nommée releases/V1.0 et apportons une petite modification sur le fichier test.js pour vérifier si ce workflow sera exécuté ou non.
Et pour le fichier test.js, voici son contenu avec une petite modification.
const greet = require('./index');
console.log("Running tests ...");
if (greet() === "Hello world") {
console.log("Test passed");
process.exit(0);
} else {
console.log("Test failed");
process.exit(1);
}
En réalisant le commit et le push , nous constatons dans le dépôt que le workflow associé aux scripts Node.js a bien été déclenché, et que les jobs ont également été exécutés. Cela signifie que les conditions d’exécution de ces jobs ont été remplies.
Parfait, nous avons donc bouclé cette partie avec succès, en validant à la fois la configuration du workflow et la gestion des dépendances entre les jobs.
Déclencheurs Run pour GitHub Workflows
Dans cette section, nous allons créer un workflow qui planifie l’exécution d’un job à un moment précis. Pour cela, créons le fichier schedule-crons-jobs.yml avec le contenu suivant :
on:
schedule:
- cron: '* * * * *' # Exécute le workflow chaque minute
- cron: '30 3 * * 6,0' # Exécute le workflow à 3h30 les samedis (6) et dimanches (0)
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Saturday or Sunday
if: github.event.schedule == '30 3 * * 6,0'
run: echo "This step will be skipped on Saturday and Sunday"
- name: Every time
run: echo "This step will run every day, every minute"
Explication du workflow:
Ce workflow est déclenché à des moments précis grâce à la configuration schedule :
- Il s’exécute chaque minute(cron :’* * * * *’).
- Il s’exécute également à 3h30 les samedis et dimanches (cron :’30 3 * * 6,0′).
Le job défini dans le workflow contient deux étapes :
- Un step qui est conditionnel et ne s’exécute pas à 3h30 les week-ends.
- Un step qui s’exécute à chaque minute sans condition.
Cela permet de planifier des exécutions automatiques avec des comportements spécifiques selon le moment.
Après avoir effectué le commit et le push , le workflow est bien présent dans le dépôt, et l’exécution des jobs dépend du temps spécifié dans le schedule .
Super, le déclencheur de workflow cron est bien implémenté et tout fonctionne parfaitement maintenant.
Déclencheurs Dispatch Manuels GitHub
Cette section concerne l’exécution de deux workflows, où un workflow doit s’exécuter après l’achèvement de l’autre. Nous allons essayer d’exécuter le workflow du script Python après celui du script Node.js. Voici le workflow pour le script Python, intitulé : Python Script Execution.
.github/workflows/python-script.yml
name: Python Script Execution
on: [push]
jobs:
check_prime:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: '3.8'
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install virtualenv
virtualenv venv
source venv/bin/activate
- name: Run Python script
run: python is_prime.py 29
Voyons maintenant la modification apportée au workflow du script NodeJS. .github/workflows/buil-and-test-nodejs.yml
name: Node.js Build and Test
on:
push:
pull_request:
types:
- opened
- reopened
branches:
- 'releases/**'
paths:
- '**.js'
workflow_run:
workflows: [ Python Script Execution]
types:
- completed
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm install
- name: Run build
run: npm run build
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm run test
Nous avons ajouté cet extrait de code, qui constitue la modification apportée à ce workflow :
workflow_run:
workflows: [ Python Script Execution]
types:
- completed
workflow_run : Ce déclencheur permet à un workflow de s’exécuter après la fin d’un autre workflow, créant ainsi des chaînes de workflows avec des dépendances.
workflows: [Python Script Execution] : Indique que le workflow actuel attend la fin du workflow nommé Python Script Execution avant de se déclencher.
types: – completed : Spécifie que le workflow actuel s’exécutera lorsque le workflow Python Script Execution sera terminé, qu’il ait réussi ou échoué.
Faisons maintenant le commit avec le message « Workflow run » et examinons les résultat s obtenus.
Nous pouvons observer que le script Python a été exécuté en premier, suivi de l’exécution du script NodeJS. Il semble que nous avons bien obtenu le résultat attendu.
les déclencheurs de workflow dispatch.
Dans cette section, nous allons créer un nouveau workflow pour pratiquer le déclenchement par workflow_dispatch. Pour cela, créez le fichier workflow-dispatch.yaml dans le dossier des workflows avec le contenu suivant :
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug # Correction de la faute de frappe ici
tags:
description: 'Test scenario tags'
required: false
type: boolean
environment:
description: 'Environment to run tests against'
type: environment
required: true
jobs:
log-the-inputs:
runs-on: ubuntu-latest
steps:
- name: Log the inputs
run: |
echo "Log level: $LEVEL"
echo "Tags: $TAGS"
echo "Environment: $ENVIRONMENT"
env:
LEVEL: ${{ inputs.logLevel }}
TAGS: ${{ inputs.tags }}
ENVIRONMENT: ${{ inputs.environment }}
Explication du contenu du wokflow :
Ce fichier YAML définit un workflow GitHub Actions qui peut être déclenché manuellement avec des entrées spécifiées par l’utilisateur :
- on :workflow_dispatch: Permet de déclencher le workflow manuellement depuis l’interface GitHub.
- inputs :Définit les paramètres que l’utilisateur peut fournir lors du déclenchement du workflow :
- logLevel :Niveau de log avec des options prédéfinies (info, warning, debug).
- tags :Tags pour le scénario de test (boolean).
- environment :Environnement pour exécuter les tests (obligatoire).
- jobs :Contient un job nommé log-the-inputs :
- runs-on :ubuntu-latest :Exécute le job sur une machine virtuelle Ubuntu.
- steps :Liste les étapes à suivre :
- Log the inputs :Affiche les valeurs des entrées fournies par l’utilisateur dans les logs du workflow.
Effectuons maintenant le push avec le message de commentaire :
Apres avoir effectué le push , on voit bien que notre workflow est bien présent dans la section actions comme ceci :
Mais pourquoi il affiche rien , car nous avons mis manuellemtìent le dispatch. Donc corriger cela, nous allons commencer le run en ccliquanr sur Run workflow.
Et puis, un formulaire des inputs s’ouvre comme ci-dessous pour les valeurs des informations.
Après avoir renseigné les inputs et cliqué sur » Run workflow « , nous obtenons le résultat suivant : le déclenchement du workflow correspondant.
Enfin, les jobs sont exécutés comme le montrent les listes ci-dessous.
Bravo, cette section conclut ce chapitre. Nous disposons désormais des connaissances nécessaires sur Git et GitHub Actions.
Formez-vous gratuitement avec Alphorm !
Maîtrisez les compétences clés en IT grâce à nos formations gratuites et accélérez votre carrière dès aujourd'hui.
FAQ
Comment configurer des déclencheurs de workflow dans GitHub Actions ?
Quelles sont les options de déclencheurs avancés dans GitHub ?
Comment utiliser des expressions CRON dans GitHub Actions ?
Comment déclencher manuellement un workflow dans GitHub ?
Quels sont les avantages des déclencheurs de workflow GitHub ?
Conclusion
En intégrant les déclencheurs de workflow GitHub Actions, vous pouvez transformer votre processus de développement en un système automatisé et efficace. Quel serait le prochain processus que vous aimeriez automatiser avec GitHub Actions ?
