Voilà un excellent exemple de ce pourquoi j'ai une stack de publication qui peut sembler compliquée au premier abord mais qui, au final, permet de faire plein de choses sympathiques. Si vous voulez en savoir plus, je vous invite à lire les autres articles que j'ai écrit à ce sujet :
Déployer Hugo via Gitea et Drone-CI
Blog
Déployer Hugo via Gitea et Drone-CI avec Caddy et MinIO
Blog
Rapidement : j'ai Drone-CI qui s'occupe de compiler et publier un site statique réalisé avec Hugo (le site que vous êtes en train de visiter). Je vais lui demander d'en faire un peu plus : parcourir le site à la recherche de liens morts et bloquer la mise en production tant que je ne les ai pas corrigés.
Il suffit de rajouter les quelques lignes suivantes dans le fichier .drone.yml du projet, dans la section steps :
- name: test_links # Nom de l'étape de la CI
image: wjdp/htmltest # Image docker utilisée
commands:
- htmltest public/ # Dans Drone-CI, le site Hugo compilé se trouve dans public/
En plus de vérifier la disponibilité des URLs, htmltest
peut (et va) effectuer d'autres tests utiles et pertinents. Il est possible de
configurer l'application
plus en détails, mais le comportement de base de htmltest me convient bien.
Un petit "soucis" à noter : cette étape doit survenir après le déploiement en production, faute de quoi les liens vers une page nouvellement créée mais pas encore déployée seront considérés comme morts. On n'empêchera donc pas les liens morts d'arriver en production, mais au moins la CI pourra nous alerter de leur présence.
Évidemment, ça augmente quelque peu le temps de mise en production (je passe de 35 secondes à 3 minutes), mais au moins, plus de liens morts, en seulement quatre lignes de conf... Simple, pour une fois !