Réutilisez vos workflows sur plusieurs projets avec les GitHub Actions

Lorsque vous implémentez l’intégration continue et le déploiement continue dans vos projets, si vous utilisez la même technologie, vous avez probablement remarqué que les workflows sont similaires ou identiques, et comme vous le savez, la duplication n’est pas du tout une bonne chose !

Pourquoi essayons-nous de mutualiser les workflows ?

• Eviter les doublons
• Simplifier la maintenance
• Corrigez les erreurs de script potentielles une seule fois
• Unifier la syntaxe et l’approche entre vos projets
• Gagnez du temps pour les prochains projets
• Partager des scripts avec d’autres équipes de votre entreprise

La question est donc de savoir comment réutiliser vos workflows et être plus efficace entre vos projets au lieu de dupliquer vos workflows ?

Workflow de base

Supposons que vous ayez un workflow pour builder un projet dotnet appelé DemoReusableTemplates. Ce projet a besoin d’une version spécifique de dotnet pour être compilé. Le workflow ressemblera donc à ceci :

name: Main

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build_dotnet:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout the code
        uses: actions/checkout@v2

      - name: Setup dotnet
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '5.0.x'

      - run: dotnet restore src/DemoReusableTemplates.csproj   

      - run: dotnet build src/DemoReusableTemplates.csproj 

Ce type de workflow peut être facilement réutilisé entre vos projets dotnet, si vous pouvez passer ces entrées en paramètres :

• le chemin du projet à builder
• la version dotnet à utiliser

C’est là qu’interviennent les actions composite !

Transformer le workflow en une action composite

Créons une action réutilisable en utilisant les actions composite pour builder notre application dotnet.

Dans un nouveau répertoire GitHub créons un dossier appelé dotnet-build et ajoutons dedans un fichier appelé action.yml. Le nom du fichier doit être action.yml ou action.yaml. Si votre fichier ne respecte pas cette convention, votre action GitHub ne fonctionnera pas.

name: "Build dotnet"
description: "Build dotnet..."
inputs:
  dotnet-version:
    description: 'The dotnet version to use'
    default: '2.1.x'
    required: false
  project-path:
    description: 'The path to the project'
    required: true

runs:
  using: "composite"
  steps: 
    - name: Setup dotnet
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: ${{ inputs.dotnet-version }}

    - run: dotnet restore ${{ inputs.project-path }}
      shell: bash

    - run: dotnet build ${{ inputs.project-path }} 
      shell: bash

Comme vous pouvez le voir ci-dessus, le chemin du projet et la version dotnet sont définis comme paramètres d’entrée. Nous les transmettons en utilisant $ et $. Ensuite, nous utilisons le mot-clé composite pour pouvoir réutiliser cette action et nous ajoutons la liste de toutes les précédentes commandes à la suite.

Comme il s’agit d’une action composite, nous ne spécifions pas de runner, nous devons donc ajouter le paramètre shell à chaque action run. Si vous ne le faites pas, vous aurez ce type de message d’erreur : Required property is missing: shell.

Comme vous l’avez probablement déjà remarqué, la dotnet-version a une valeur par défaut définie sur 2.1.x donc ce n’est pas obligatoire de l’allimenter.

Créer un repository dédié

Pour référencer un composite dans vos différents workflows et projets, il doit être enregistré dans un répertoire spécifique. Ce répertoire commun contiendra différents composites avec différentes versions :

Vous pouvez avoir un projet référençant l’action composite dans sa version v0.0.1 et un autre référençant la version v0.0.2.

Dans cet esprit, commitons et poussons cette action composite dans un repository dédié. Ajoutez ensuite un tag par exemple : v0.0.1.

Référencez votre action composite dans votre workflow

L’idée est maintenant de mettre à jour notre premier workflow avec notre nouvelle action :

name: Main

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build_dotnet:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout the code
        uses: actions/checkout@v2

      - name: Build dotnet
        uses: damienaicheh/demo-action-composite/dotnet-build@v0.0.1
        with:
          dotnet-version: 5.0.x
          project-path: src/DemoReusableTemplates.csproj

Comme vous pouvez le voir ci-dessus, nous référençons l’action dotnet-build en utilisant le nom du référentiel avec le chemin complet vers le dossier qui contient le action.yml. Aussi, pour spécifier la version de cette action composite que nous voulons utiliser, nous ajoutons le numéro de la balise à la fin. Ici, c’est @v0.0.1.

Touche finale

Comme vous l’avez vu, il est très facile de réutiliser vos workflows entre vos projets et d’éviter les doublons. N’hésitez pas à créer vos propres répositories d’action composite ! Vous trouverez les deux référentiels GitHub de cet article disponibles ici :

• Projet dotnet console
• Répertoire d’actions composite

Happy coding!

N'hésitez pas à me suivre sur Twitter pour ne pas rater mon prochain tutoriel !