[Archive — École 42] Github Actions
💡 Cet article a été rédigé dans le but d’introduire mes camarades (école 42) aux actions Github afin que leurs tests soient exécutés automatiquement.
Introduction
Depuis mon passage à l’école 42, le sujet “ft_printf” a été modifié. En effet, il a été raccourci, ainsi la partie ”obligatoire” s’est vue amputée de certaines options (précision ‘.’, padding ‘0’ et l’alignement à gauche ‘-’ sont devenus des bonus).
Ce sujet est l’un des premiers du cursus (il s’agit principalement de re coder la fonction printf de la librairie standard C en gérant différents types de données (int, char, string, unsigned, pointeur…)).
Il n’était pas rare, étant donné la complexité de la gestion des options (et des “edge cases” associés) d’observer chez les étudiants (dont moi !) des projets assez conséquents (nombreux fichiers) avec un code qui respecte certes “la norme” (= conventions syntaxiques de l’école 42), mais qui sont relativement “sales” (ne respectant pas nécessairement les principes du Clean Code).
Ayant compris l’importance du Clean Code en entreprise, j’ai pris le temps de corriger ce projet, afin de l’adapter au sujet actuel et de le rendre plus lisible :
J’ai également profité de cette occasion pour ajouter différentes “Github Actions” (également découvertes en entreprise) pour faire tourner 2 jobs:
- Un job qui lance un script de tests (écrits par paulo-santana).
- Un job qui permet de vérifier le respect des conventions attendues (qu’on appelle “norminette”).
Pour cela, j’ai créé une “organisation” Github (gratuite), afin de bénéficier des “Github Hosted Runners” (dont macOS!).
J’ai donc pu configurer mon “job” qui tournera lorsque qu’une PR (Pull Request) sera créée (ou chaque fois qu’un merge sur la branche correspondante sera fait).
Attention, ce type de fichiers (de configuration) doit impérativement être placé dans .github/workflows et contenir idéalement l’extension .yml :
name: norminette
on:
push:
branches: [ "master" ]
pull_request:
branches: [ "master" ]
jobs:
norminette_job:
runs-on: ubuntu-latest
name: norminette
steps:
- uses: actions/checkout@v2
- uses: alexandregv/norminette-action@v3
with:
flags: './project'Le mot clé “flags” permet de définir le chemin vers le dossier (= ‘path’) contenant les fichiers à vérifier syntaxiquement.
Ici, on peut constater que la “norminette” est bien passée sur tous les fichiers du projet, l’output étant le même que si la commande avait été lancée en ligne de commande :
# Équivalent en local
norminette ./project/
Le deuxième job a été écrit entièrement par mes soins de la façon suivante :
name: mandatory tests
on:
push:
branches: [ "master" ]
pull_request:
branches: [ "master" ]
jobs:
build:
# Vous pourriez même faire plusieurs jobs pour vérifier la compilation
# sous différent os ! (ubuntu-latest par exemple, ou autre !)
runs-on: macos-latest
steps:
- uses: actions/checkout@v3
- name: mandatory tests
# J'ai ajouté quelques commandes pour observer ce qu'il se passe dans le runner
run: ls -lR; make; cd ./tester; make; ./test m
# On aurait pu faire simplement
# run: make; ./tester/test m
shell: bash
On peut observer ici que les tests “mandatory” ont bien rencontré un succès :
Voici donc comment chaque étudiant pourrait mettre en place une petite “CI” afin d‘exécuter automatiquement les vérifications nécessaires à la validation de son projet.
Si certaines notions comme les Pull Requests, les Github Actions ou la “CI/CD” sont encore méconnues, je vous invite à faire des recherches complémentaires car vous verrez que ce sont des connaissances nécessaires (et bien utiles!) à posséder en entreprise 🤩 !
