Automatisez vos tests avec GitHub Actions

GitHub Actions est un outil d'intégration et de déploiement continus (CI/CD) permettant d'automatiser les workflows et dans notre cas, nos workflows Laravel. Il facilite l'exécution de tests, le déploiement et d'autres tâches essentielles directement depuis un repository GitHub.

Pour illustrer aujourd'hui, nous allons utiliser les GitHub Actions pour exécuter des tests automatisés après chaque push ou pull request. Nous aborderons ensemble les étapes essentielles d'un workflow CI/CD pour un projet Laravel.

Passons à l'action !

Les GitHub Actions sont définies dans un fichier YAML nommé <nom du workflow>.yml et sont listées dans le dossier .github/workflows à la racine de votre projet. Vous pourrez stocker autant de workflows que votre projet en nécessite.

Pour créer notre action, on lui attribue généralement un nom dans l'en-tête. Personnellement, j'utilise souvent celui du fichier YAML correspondant.

1name: test-my-laravel-project

Ensuite, on définit les événements qui déclenchent l'exécution du workflow. Ici, on exécute les tests à chaque pull request sur la branche master.

1on:
2  pull_request:
3    branches: [ master ]

Il est possible de définir plusieurs événements de déclenchement, par exemple à chaque push sur master. D'autres déclencheurs sont disponibles, vous pouvez retrouver la liste complète sur la documentation officielle.

Pour les utilisateurs de mono-repositories ou ceux qui ont créé une inception de projet dans un même repository, il est possible de préciser les chemins des fichiers à surveiller pour être déclenchés.

L'option on.*.paths permet de définir les chemins des fichiers à surveiller déclenchant l'action.

1on:
2  push:
3    branches: [ master ]
4    paths:
5      - 'mon-sous-projet/**'
6  pull_request:
7    branches: [ master ]

Pour vous assurer de travailler dans le bon répertoire, il vous faudra alors définir un répertoire de travail par défaut avec l'option defaults.run.working-directory.

1defaults:
2  run:
3    working-directory: ./mon-sous-projet

Vous pourriez également avoir besoin de définir des variables d'environnement pour votre workflow. Il vous suffira de constituer votre liste personnalisée avec l'option env.

1env:
2  <ma variable d'env>: <ma valeur>
3  php_version: 8.3

Le cœur de votre workflow est constitué des jobs, qui sont des étapes d'exécution de votre pipeline. Chaque job est exécuté dans un environnement virtuel et peut être configuré pour s'exécuter en parallèle ou en séquence. Nous n'allons créer qu'un seul job pour notre pipeline, vous pouvez bien sûr retrouver les options dans la documentation officielle.

Notre job est nommé test et s'exécute sur une machine virtuelle Ubuntu.

Comme vu plus haut, il est configuré pour démarrer automatiquement lors d'un push sur une branche en cours de pull request vers master. Cela signifie que si vous êtes un "pusher" fou, vous pouvez vous attendre à ce que votre pipeline s'exécute à chaque push sur votre branche de travail.

Pour ne pas encombrer les ressources de GitHub, il est possible de limiter le nombre de jobs en cours d'exécution avec l'option concurrency. Selon votre plan payant (ou non) GitHub, vous pourrez ainsi limiter vos dépenses et personnellement, vous économiserez votre patience.

Ici, nous avons défini un groupe de concurrence pour notre job test en utilisant des variables d'environnement pour le nom du groupe et le nom de la branche. Si vous poussez (push) plusieurs fois en même temps, GitHub Actions annulera les jobs en cours d'exécution pour ne conserver que le dernier job.

1jobs:
2 
3  test:
4    runs-on: ubuntu-latest
5    concurrency:
6      group: test-my-laravel-project-${{ github.workflow }}-${{ github.ref }}
7      cancel-in-progress: true

Enfin, dans notre job test, nous définissons les étapes à suivre pour exécuter les tests de notre projet Laravel.

Tout d'abord, nous commencerons par récupérer le code source avec actions/checkout@v3, qui va s'occuper de cloner le repository pour nous.

1steps:
2 
3  - name: Checkout project
4    uses: actions/checkout@v3

On personnalisera ensuite notre environnement en installant PHP 8.3 avec shivammathur/setup-php@v2, si nécessaire, lors de cette étape, nous pourrons installer des extensions PHP ou des outils supplémentaires.

 1steps:
 2 
 3  - name: Checkout project
 4    uses: actions/checkout@v3
 5 
 6  - name: Initialize PHP ${{ env.php_version }}
 7    uses: shivammathur/setup-php@v2
 8    with:
 9      php-version: ${{ env.php_version }}
10      coverage: pcov

Une fois l'environnement configuré, il sera nécessaire d'installer les dépendances de notre projet à l'aide de composer, l'option --no-interaction permettra d'éviter les interactions nécessitant un input de l'utilisateur et sera idéale dans le cadre d'une Github Action.

 1steps:
 2 
 3  - name: Checkout project
 4    uses: actions/checkout@v3
 5 
 6  - name: Initialize PHP ${{ env.php_version }}
 7    uses: shivammathur/setup-php@v2
 8    with:
 9      php-version: ${{ env.php_version }}
10      coverage: pcov
11 
12  - name: Composer install
13    run: |
14      composer validate --strict
15      composer install --optimize-autoloader --no-interaction --prefer-dist

Pour finir, nous n'avons plus qu'à lancer les tests de notre application à l'aide de la commande Artisan :

 1steps:
 2 
 3  - name: Checkout project
 4    uses: actions/checkout@v3
 5 
 6  - name: Initialize PHP ${{ env.php_version }}
 7    uses: shivammathur/setup-php@v2
 8    with:
 9      php-version: ${{ env.php_version }}
10      coverage: pcov
11 
12  - name: Composer install
13    run: |
14      composer validate --strict
15      composer install --optimize-autoloader --no-interaction --prefer-dist
16 
17  - name: Test
18    run: php artisan test

actions/checkout@v3 et shivammathur/setup-php@v2 sont des actions prédéfinies par GitHub Actions. Vous pouvez retrouver la liste des actions disponibles sur le GitHub Marketplace.

C'est fait ! Nous avons automatisé les tests de notre projet Laravel avec GitHub Actions !

Bien que minimaliste, ce workflow constitue un bon point de départ pour automatiser vos tests et vous aider à maintenir la qualité de votre code.

Pour le compléter, vous pourriez ajouter des étapes supplémentaires pour déployer votre application, notifier vos équipes, publier des rapports de couverture de code, analyser la qualité du code, etc.

Source : https://gist.github.com/abenevaut/c86ab8d559b92f2d93b028a0e6e832d9