Cet article est le premier d’une série sur Github Actions et la mise en place d’une chaîne CI/CD.

• Github Actions 2.0 pour une CI .NET Core
• Github Actions 2.0 : Déploiement Continu sur Azure
• Github Actions : Azure CLI & Service Principal

Il y a quelques jours j’ai reçu le Saint-Graal: l’activation de la fonctionnalité Actions de Github.

Il s’agit là de pouvoir gérer ses pipelines de Continuous Delivery directement depuis Github.

Après avoir pu jouer un peu, je vais pouvoir vous faire un petit état des lieux sur Github Actions et notamment l’utilisation pour construire un pipeline d’intégration continue pour vos applications dotnet core.

Vous pourrez même afficher un petit badge ;)

Préparation

Tout d’abord, il faut avoir Github Actions activé. Oui ça paraît con, mais je préfère le dire avant qu’on me dise “Ouiiin ça marche pas !”. Pour ceux qui ne l’auraient pas encore et se tiennent prêts à me dire “Oh tu te la pètes avec ton accès à Github Actions”, sachez qu’il semble y avoir des vagues de validation en masse ces derniers jours. Alors allez faire votre demande d’accès rapidement ou attendez le 13 novembre pour la disponibilité générale.

Ensuite, il vous faut un repository avec le code d’une application dotnet core. Si vous n’en avez pas, vous pouvez toujours forker le repository suivant : https://github.com/MicrosoftDocs/pipelines-dotnet-core. C’est celui que j’utiliserai dans ma démo.

Workflow template

Passons aux choses sérieuses.

Dans votre repository, cliquez sur Actions.

Dans la fenêtre Actions, vous pouvez choisir de partir sur un workflow complètement vide ou de choisir un template correspondant à votre projet.

Pour cet exemple, nous choisirons le template ASP.NET Core. Vous pouvez aussi partir d’un template vide et tout retaper mais bon…

Une fois votre template choisi, Github crée pour vous un fichier au format YAML. C’est là que la magie opère.

Si vous avez déja touché au YAML avec Azure DevOps ou un autre gestionnaire de pipeline, alors vous ne serez pas dépaysés, même si des spécifités existent entre les éditeurs: “Just another flavor of YAML” ;) Pour les autres et ceux qui voudraient connaître les fonctionnalités disponibles dans le YAML à la sauce Github Actions, vous pouvez vous rendre sur la documentation associée.

Build

Regardons un peu notre fichier YAML de workflow.

Il faut tout d’abord définir le “trigger” ou “déclencheur” du workflow. A chaque push sur le repository, le workflow sera déclenché.

on: [push]

Ok, maintenant on s’attaque au build puisque l’on souhaite réaliser notre intégration continue.

jobs:
build:

On fait du .NET Core donc on peut compiler sur une distrbution Linux et on ne va pas se priver.

runs-on: ubuntu-latest

On utilise ici une action packagée et proposée par Github pour installer la CLI dotnet sur l’agent en spécifiant la version.

uses: actions/setup-dotnet@v1
with:
dotnet-version: 2.2.108

Enfin, on utilise la CLI dotnet pour lancer la commande de build de notre projet. Nous ne spécifions pas le dossier dans cet exemple mais, selon votre arborescence de repository, il faudra peut-être spécifier le ou les fichiers .csproj à compiler.

- name: Build with dotnet
  run: dotnet build --configuration Release

Logs

Une fois le fichier sauvé et inclus dans le répository Github, l’action sera déclenchée et vous pourrez suivre le déroulement de celui-ci.

Par défaut un email est envoyé en cas d’échec du workflow.

Vous pouvez également ajouter un petit badge dans le déscriptif de votre repository ou tout autre endroit pertinent en utilisant le format d’url suivant :

https://github.com/{github_id}/{repository}/workflows/{workflow_name}/badge.svg

Cool, on a créé un workflow qui, à chaque push sur master, démarre un build sur notre projet et nous informe en cas d’erreur. Essayons d’aller un peu plus loin.

Tests

“Hey Michaël, tu nous saoules avec tes tests sur tous tes projets et tu crois qu’on va te laisser t’en sortir comme ça ?”

Vous avez raison, notre application compile, c’est bien mais pas suffisant pour une intégration continue. Voyons donc comment effectuer quelques tests unitaires.

La CLI dotnet comporte une commande test qu’il ne nous reste qu’à ajouter comme step de notre fichier de workflow :

- name: Test with dotnet
  run: dotnet test --configuration Release

Là encore, je ne précise pas les projets de tests car mon arborescence me le permet, mais libre à vous de les spécifier.

Package & Artifacts

Une fois notre Build effectuée et les tests passés avec succès, dans une optique de pipeline d’intégration continue (voire de déploiement continu), il nous faut générer un package de notre application.

Pour cela, rien de plus simple, il nous suffit de rajouter quelques steps.

Tout d’abord, nous allons packager notre application :

- name: Package with dotnet
  run: dotnet publish --configuration Release

Et enfin, nous allons publier le résultat dans un artifact.

name: Publish artifact
uses: actions/upload-artifact@master
with:
  name: webapp
  path: bin/Release/netcoreapp2.2/publish

Nous utilisons ici l’action packagée et proposée par Github actions/upload-artifact. Cette action nécessite de définir un nom ainsi que le répertoire à inclure dans cet artifact.

Une fois ces actions ajoutées et ajustées à vos besoins, vous devriez voir apparaître un nouveau bouton en haut à droite de vos logs de worflow.

Conclusion

Dans cet article, nous avons découvert Github Actions 2.0. Cela pourra s’avérer désuet pour ceux qui connaissaient déjà Actions ou Azure DevOps, mais il me semble que l’outil soit peu connu et notamment dans l’écosystème .NET. De plus, la mise en place d’une intégration continue en quelques minutes, de manière gratuite et sans sortir de Github me paraît vraiment intéressante.

Dans un prochain article, nous découvrirons Github Actions for Azure.

A bientôt !