Postula

La première version du blog fonctionnait ainsi:

.
└── Private_Github (main branch)/
    ├── .Github/
    │   └── workflows/
    │       └── fichier_workflow.yml
    ├── archetypes/
    │   └── ...
    ├── content/
    │   └── ...
    ├── public
    └── ...

Le fichier ‘fichier_workflow.yml’ est le point de départ du CI/CD de Github. Il contient des instructions ordonnées que vous pouvez retrouver dans mon article précédent.

Pour résumer les étapes qui me permettaient de générer le blog et le publier:

.
├── Sur ma machine (Windows)/
│   ├── 1) Création d'un article
│   ├── 2) Génération du blog static avec la commande "hugo"
│   ├── 3) git commit
│   └── 4) git push
├── Sur Github (en auto)/
│   └── 5) workflow Github/
│       └── Pousse le dossier "public" via FTP sur l'hébergement
└── Blog à jour !

Constat à la longue

Le problème de ce fonctionnement, c’est que parfois j’oublie de générer le contenu avec Hugo une fois l’article terminé. J’en écris pas des tonnes et en plus j’écris tous les 36 du mois, du coup je ne prends pas les bonnes habitudes.

Un autre c’est que le fait de générer le site avant de faire un push, mon push devient assez conséquent. Bien que j’essaye au maximum d’éviter les images ou les choses qui prennent vite du poids, si je peux éviter de générer en local ça me va. Je ne vois pas l’intérêt de garder l’historique du site en statique sur le git, c’est énergivore et “datavore” pour rien.

Objectifs

  1. Le premier objectif est de réduire les étapes ci-dessus en générant le site dans le workflow Github. En tant qu’adminsys j’aime être fainéant (ne me faites pas dire ce que je n’ai pas dit, on est pas tous comme ça !). Donc, pour corriger un problème humain, ben je fais ce que je fais de mieux, j’automatise, non ?

  2. Un deuxième objectif est de supprimer l’utilisation de FTP qui ne me plaisait pas du tout. Je pensais que mon hébergeur ne proposait que ça, or j’ai découvert la possibilité d’utiliser SSH (donc SFTP) !

Simplifier

Pour y arriver, j’ai cherché un nouveau module d’action Github qui pourrait générer le blog lui-même, plutôt que le faire moi-même avant de commit. Et je l’ai trouvé: Actions-GH-Pages par Shohei Ueda. Merci ! La documentation se suffit à elle-même.

Mais je n’ai finalement pas utilisé ce module, pour je ne sais quelle raison (tenter de maitriser une nouvelle chose à minuit peut-être ? ) impossible de faire ce que je voulais. J’ai fini par bloquer sur le fait que le module générait bien le contenu statique mais il le stockait dans une branche “gh-pages”. J’ai tenté plusieurs techniques pour envoyer les données de cette nouvelle branche vers l’hébergement, sans y arriver. Après réflexion, en écrivant ce billet et en étant arrivé au bout du projet, je pense que le module fonctionnait très bien, seulement j’avais des erreurs de Markdown dans mon article…de fait la génération du site ne se faisait pas sur ce fichier, ce qui m’amenait à penser que rien ne s’envoyait.

J’ai donc trouvé une autre technique, apportée par Scott W Harden: installer directement GoHugo dans le container et générer le site. L’avantage de cette technique, c’est la rapidité du processus ! Les perfs sont bien meilleures qu’avec le module AGP (de l’ordre d’une dizaine de secondes).

Sécuriser

J’ai cherché également un module permettant de faire un transfert de fichier via SSH (SFTP), SFTP-Deploy-Action répond parfaitement aux besoins. Merci à WLIXCC ! On peut faire la connexion SSH via une clé privée (préférez cette méthode si votre hébergeur le permet!) ou le classique user/passwd. Dans un premier temps je vais utiliser la deuxième méthode pour valider que le module fonctionne, une fois fait je tenterai de générer une clé SSH.

Nouveau schéma de déploiement

Donc, si on met ça simplement sous forme de hierarchie d’actions ça donne ça:

Sur ma machine (Linux: ça y est, mes poils sont assez longs pour être un homme 😜 )
  1) Création d'un article
  2) git commit
  3) git push
Sur Github (en auto)
  4) workflow Github
  └── Génère le site statique
  └── Pousse le dossier "public" via SFTP sur l'hébergement
Blog à jour !

Allez, on met ça en place

  1. Dans la branche “main” j’ai renommé le fichier YAML en “Generate_Blog.yml” pour être plus propre.

  2. Il faut créer/modifier les secrets Github nécessaires au workflow:

    • FTP_USERNAME (oui j’ai gardé les noms de certains…en FTP)
    • FTP_SERVER
    • FTP_PORT (si votre hébergeur est malin et n’utilise pas le 22 :) )
    • SSH_PASSWORD

  3. Le nouveau YAML Generate_Blog.yml

name: Generate and publish static Website
on:
push:
  branches:
    - main
jobs:
web-deploy:
  name: 🎉 Generate_Publish_Blog
  runs-on: ubuntu-latest
  permissions:
    contents: write
  concurrency:
    group: ${{ github.workflow }}-${{ github.ref }}
    
  steps:
    - name: ✅ Checkout
      uses: actions/checkout@v3

    - name: ⚙️ Setup Hugo
      env:
        HUGO_VERSION: 0.116.1 # <<< oui c'est manuel la version, à faire évoluer pour le rendre automatique.
      run: |
        mkdir ~/hugo
        cd ~/hugo
        curl -L "https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_Linux-64bit.tar.gz" --output hugo.tar.gz
        tar -xvzf hugo.tar.gz
        sudo mv hugo /usr/local/bin            

    - name: 🛠️ Build minified
      run: hugo --minify

    - name: 📥 Upload static blog
      uses: wlixcc/SFTP-Deploy-Action@v1.2.4
      with:
          username: ${{ secrets.FTP_USERNAME }}
          server: ${{ secrets.FTP_SERVER }}
          port: ${{ secrets.FTP_PORT }}
          local_path: './public/*'
          remote_path: './public_html/' ## Vérifiez où vous arrivez par défaut via le SSH, en fonction de l'hébergeur ça n'est pas identique.
          password: ${{ secrets.SSH_PASSWORD }}
          sftp_only: true ## Si votre hébergeur filtre sur uniquement du SSH, je vous conseille de le mettre pour être tranquille.

Je ne vous ai évidemment publié que le fichier “validé”, j’ai fait de nombreux tests infructueux avant pour comprendre le fonctionnement et les interactions des modules avec le git. Je ne suis pas très à l’aise avec ces technos pour le moment. Cette conf est un mélange de plusieurs choses que j’ai pu trouver ça et là et que j’ai adapté.

Il me restera à modifier le “password” en “ssh_private_key” dans la conf et dans les secrets du repository Github.

Conclusion

Cette technique est bien plus simple pour moi et m’évitera d’oublier certaines étapes manuelles. Du moment que je push sur le git, tout sera publié sur le blog.

La cerise sur le chihuahua, c’est que je reçois un mail à la fin du job s’il a planté pour quelconque raison.

Si vous voyez ce billet, c’est que je ne me suis pas planté 😄

A bientôt !