Introduction à GitHub Actions

GitHub Actions est un puissant outil d’automatisation fourni par GitHub. Il vous permet d’automatiser diverses tâches et flux de travail directement dans votre dépôt GitHub. Avec GitHub Actions, vous pouvez construire, tester et déployer votre code facilement.

Principales fonctionnalités de GitHub Actions

• Automatisation des workflows: GitHub Actions vous permet d’automatiser des tâches répétitives, telles que la construction et le test de votre code, le déploiement d’applications, et plus encore.

• Événements déclencheurs: Les actions sont déclenchées par des événements qui se produisent dans votre dépôt, tels qu’une poussée vers une branche spécifique, la création d’une demande de tirage (pull request), ou la création d’une nouvelle version.

• Flexibilité et personnalisation: Vous pouvez créer des workflows personnalisés adaptés à vos besoins spécifiques. GitHub Actions prend en charge un large éventail de langages de programmation et offre un ensemble riche d’actions et d’outils.

• Communauté active: GitHub Actions dispose d’une communauté dynamique qui partage des workflows et des actions, vous permettant de tirer parti de solutions existantes et de collaborer avec d’autres personnes.

Organisation du workflow dans le cadre de ce portfolio

Pour simplifier le déploiement de ce portfolio, nous allons définir un workflow qui effectue les tâches suivantes :

• Construction du site: Le workflow doit construire le site à partir du code source, en utilisant le framework Hugo. Le site sera conteneurisé dans une image Docker.

• Déploiement du site: le workflow doit déployer le site sur un serveur distant, en utilisant Docker.

Pourquoi je l’utilise dans le cadre du développement de ce portfolio/blog ?

Ce processus m’aide à tirer parti de la puissance du versioning avec GitHub, facilitant l’identification des phases de progression et des changements dans mon portfolio. La phase de test, ensuite, me permet de détecter plus aisément et rapidement les erreurs, telles que des redirections de liens incorrectes qui ne bloquent pas la compilation du site. L’automatisation, pour sa part, représente un gain de temps considérable, en permettant l’extraction des modifications, la re-compilation du site, ainsi que la reconstruction et le lancement de l’image docker du portfolio. Avec les configurations réseau et proxy déjà établies, il suffit d’un git push pour activer le workflow et déployer rapidement une nouvelle version du site.

Premiers pas

On commence par créer un workflow l’onglet actions sur Github :

Puis on édite le fichier main.yml pour définir les étapes du workflow.

Ce fichier peut également être directement intégré dans le dépôt, dans le dossier .github/workflows/main.yml.

Pour notre uilisation, notre fichier main.yml ressemblera à ceci :

name: CI/CD Pipeline

on:
  push:
    branches:
      - main  # ou votre branche de déploiement

jobs:
  build-and-deploy:
    runs-on: self-hosted, <votre-étiquette-de-runner>  # Utilise l'étiquette de votre runner auto-hébergé
    # des runners peuvent être fournis par github 

    steps:
    - name: Check out the repo
      uses: actions/checkout@v2
      with:
        submodules: 'recursive' # pour les sous-modules git et dans notre cas le thème gokarna

    - name: hugo build
      run: hugo --minify

    - name: Build Docker Image
      run: docker build . -t <nom-du-conteneur>:latest

    - name: Stop the existing container
      run: docker stop <nom-du-conteneur> || true

    - name: Remove the old container
      run: docker rm <nom-du-conteneur> || true

    - name: Run the new container
      run: docker run -d --name <nom-du-conteneur> -p <port-externe>:<port-interne> <nom-du-conteneur>:latest

Il est important d’ajouter vos tests unitaires et de sécurité dans le workflow pour garantir la qualité du code et la sécurité de votre application.

Maintenant que notre workflow est défini, nous allons créer notre runner auto-hébergé.

Pour cela, on se rend dans les paramètres du dépôt, puis dans l’onglet Actions. On clique sur “new runner” puis “new self hosted runner” et on suit les instructions pour installer le runner sur notre machine.

La commandes pour l’installation se génère en fonction de notre système d’exploitation :

Sur notre machine auto-hébergée, on crée un utilisateur dédié pour le runner, puis on installe le runner avec la commande générée.

adduser ahasera usermod -G sudo ahasera

On peut ensuite démarrer le runner avec la commande ./run.sh start et vérifier qu’il est bien actif dans les paramètres du dépôt.

Désormais notre runner est actif et notre workflow est prêt à être déclenché.

On teste avec un push sur notre branche de déploiement, et on vérifie que le workflow se déclenche bien et que le site est bien déployé.

Notre pipeline CI/CD est maintenant opérationnel. Nous avons automatisé le processus de construction et de déploiement de ce portfolio, ce qui nous permet de gagner du temps et de réduire les risques d’erreurs.