Article original : How to set up a lightweight, tool-agnostic CI/CD flow with GitHub Actions

L'outil agnostique est le concept ingénieux selon lequel vous devriez pouvoir exécuter votre code dans divers environnements. Avec de nombreuses applications d'intégration continue et de développement continu (CI/CD) disponibles, l'outil agnostique offre aux développeurs un grand avantage : la portabilité.

Bien sûr, faire fonctionner votre CI/CD partout est un défi de taille. Les applications CI populaires pour les dépôts GitHub utilisent à elles seules une multitude de langages de configuration couvrant Groovy, YAML, TOML, JSON, et plus encore... tous avec des syntaxes différentes, bien sûr. Porter les workflows d'un outil à un autre est plus qu'un processus d'une tasse de café.

Image

L'introduction de GitHub Actions a le potentiel d'ajouter un autre outil au mélange ; ou, pour la bonne configuration, de simplifier considérablement un workflow CI/CD.

Avant cet article, j'accomplissais mon flux CD avec plusieurs applications assemblées. J'utilisais AWS Lambda pour déclencher les builds du site selon un calendrier. J'avais Netlify qui construisait sur les déclencheurs de push, ainsi que l'optimisation des images, puis poussait mon site vers le dépôt public Pages. J'utilisais Travis CI dans le dépôt public pour tester le HTML. Tout cela fonctionnait en conjonction avec GitHub Pages, qui héberge réellement le site.

Je n'utilise maintenant que la version bêta de GitHub Actions pour accomplir toutes les mêmes tâches, avec un Makefile portable d'instructions de build, et sans aucune autre application CI/CD.

Apprécier le shell

Que ont la plupart des outils CI/CD en commun ? Ils exécutent vos instructions de workflow dans un environnement shell ! C'est merveilleux, car cela signifie que la plupart des outils CI/CD peuvent faire tout ce que vous pouvez faire dans un terminal... et vous pouvez faire presque n'importe quoi dans un terminal.

Surtout pour un cas d'utilisation contenu comme la construction de mon site statique avec un générateur comme Hugo, tout exécuter dans un shell est une évidence. Pour dire à la boîte magique quoi faire, nous devons simplement écrire des instructions.

Bien qu'un script shell soit certainement l'option la plus portable, j'utilise le toujours très portable Make pour écrire mes instructions de processus. Cela me fournit certains avantages par rapport au simple script shell, comme l'utilisation de variables et de macros, et la modularité des règles.

Je suis entré dans les détails de mon Makefile dans mon dernier article. Regardons comment faire fonctionner GitHub Actions pour l'exécuter.

Utiliser un Makefile avec GitHub Actions

Pour notre point sur la portabilité, mon Makefile magique est stocké directement à la racine du dépôt. Puisqu'il est inclus avec le code, je peux exécuter le Makefile localement sur n'importe quel système où je peux cloner le dépôt, à condition de définir les variables d'environnement. Utiliser GitHub Actions comme mon outil CI/CD est aussi simple que de faire fonctionner Make.

J'ai trouvé le guide de syntaxe des workflows GitHub Actions assez simple, bien que long sur les options. Voici la configuration nécessaire pour exécuter le Makefile.

Le fichier de workflow à .github/workflows/make-master.yml contient ce qui suit :

name: make-master

on:
  push:
    branches:
      - master
  schedule:
    - cron: '20 13 * * *'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
        with:
          fetch-depth: 1
      - name: Exécuter le Makefile
        env:
          TOKEN: ${{ secrets.TOKEN }}
        run: make all

Je vais expliquer les composants qui font fonctionner cela.

Déclencher le workflow

Actions prend en charge plusieurs déclencheurs pour un workflow. En utilisant la syntaxe on, j'ai défini deux déclencheurs pour le mien : un événement push vers la branche master uniquement, et un travail cron planifié.

Une fois le fichier make-master.yml dans votre dépôt, l'un de vos déclencheurs fera en sorte qu'Actions exécute votre Makefile. Pour voir comment s'est déroulée la dernière exécution, vous pouvez également ajouter un badge amusant au README.

Une chose un peu bidouillée

Parce que le Makefile s'exécute à chaque push vers master, je recevais parfois des erreurs lorsque le build du site n'avait aucun changement. Lorsque Git, via mon Makefile, tentait de commiter vers le dépôt Pages, aucun changement n'était détecté et le commit échouait de manière ennuyeuse :

nothing to commit, working tree clean
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
Makefile:62: recipe for target 'deploy' failed
make: *** [deploy] Error 1
##[error]Process completed with exit code 2.

J'ai trouvé des solutions qui proposaient d'utiliser diff pour vérifier si un commit devait être fait, mais cela peut ne pas fonctionner pour des raisons. En tant que solution de contournement, j'ai simplement ajouté l'heure UTC actuelle à ma page d'index afin que chaque build contienne un changement à commiter.

Environnement et variables

Vous pouvez définir l'environnement virtuel pour votre workflow à exécuter en utilisant la syntaxe runs-on. Le choix évident et le meilleur que j'ai fait est Ubuntu. Utiliser ubuntu-latest me donne la version la plus à jour, quelle qu'elle soit lorsque vous lisez ceci.

GitHub définit certaines variables d'environnement par défaut pour les workflows. L'action actions/checkout avec fetch-depth: 1 crée une copie du dernier commit de votre dépôt dans la variable GITHUB_WORKSPACE. Cela permet au workflow d'accéder au Makefile à GITHUB_WORKSPACE/Makefile. Sans utiliser l'action de checkout, le Makefile ne sera pas trouvé, et j'obtiens une erreur qui ressemble à ceci :

make: *** No rule to make target 'all'.  Stop.
Running Makefile
##[error]Process completed with exit code 2.

Bien qu'il existe un jeton GITHUB_TOKEN secret par défaut, ce n'est pas celui que j'ai utilisé. Le jeton par défaut n'est valable que localement pour le dépôt actuel. Pour pouvoir pousser vers mon dépôt GitHub Pages séparé, j'ai créé un jeton d'accès personnel avec un accès public_repo et je le transmets en tant que variable chiffrée secrets.TOKEN. Pour un guide étape par étape, voir Création et utilisation de secrets chiffrés.

Outillage portable

Le point positif de l'utilisation d'un simple Makefile pour définir la majeure partie de mon processus CI/CD est qu'il est complètement portable. Je peux exécuter un Makefile n'importe où j'ai accès à un environnement, ce qui est le cas de la plupart des applications CI/CD, des instances virtuelles, et, bien sûr, sur ma machine locale.

L'une des raisons pour lesquelles j'aime GitHub Actions est que faire fonctionner mon Makefile a été assez simple. Je pense que la syntaxe est bien faite - facile à lire, et intuitive lorsqu'il s'agit de trouver une option que vous recherchez. Pour quelqu'un utilisant déjà GitHub Pages, Actions offre une expérience CD assez transparente ; et si cela devait changer, je peux exécuter mon Makefile ailleurs. _(_)_/