Quand j’ai entamé le processus de migration (toujours non terminé) de WordPress vers Hugo, j’ai rapidement décidé de mettre en place une pipeline de CI/CD à propos de laquelle j’ai fourni de nombreux détails dans cet article.
J’avais décidé de partir sur les outils AWS, en particulier CodeCommit et CodeBuild, pour me familiariser avec et voir ce qu’ils valaient par rapport à des solutions comme GitHub ou GitLab.
Ça m’a pris beaucoup plus de temps que prévu pour arriver à un résultat satisfaisant.
En partie à cause des limites des outils.
En partie à cause de leur complexité intrinsèque.
En partie à cause du manque de documentation.
En partie à cause de mon manque d’implication pour chercher à vraiment comprendre.
Résultat, j’étais moyennement convaincu, surtout que la Web UI, bien que supérieure à Azure DevOps, est tout sauf engageante.
Mais ça avait le mérite de tourner de manière tout à fait stable depuis près d’un an.
Et en plus ça ne m’a pas coûté un centime !
Malgré un repository de 1.5Gb, plus de 200 builds, et de nombreux Gb de données publiées sur Rsync.net ; je ne suis jamais sorti des limites du Free Tier des services.
Depuis, j’ai eu l’occasion de construire des pipelines sur d’autres outils, et surtout, en reconstruisant à zéro mon homelab, j’ai pris conscience de la disponibilité des Actions sur Gitea et en trois commits, j’ai pu constater que ça fonctionnait plutôt bien ; avec pour avantage colossal, d’être une copie quasi-conforme aux GitHub Actions avec lesquelles j’étais déjà familier et qui ont la plus grosse communauté et le plus gros écosystème à ce jour.
L’idée de migrer la pipeline Elauhel sur mon instance Gitea me trottait dans la tête.
Fin juillet, AWS a annoncé qu’ils n’autorisaient plus l’accès aux nouveaux utilisateurs à CodeCommit.
En langage AWS, ça veut dire “on a décidé d’arrêter de développer ce service, donc pas de nouveaux usages, et pour les anciens, on laisse la lumière allumée, et en cas de pépin, on pourra dépanner, mais, idéalement, il faudrait plier les gaules”.
Ce qui, forcément, fait grincer les dents de certains utilisateurs, mais reste bien plus respectueux que ce que fait le voisin de nuage.
Me concernant, ça n’avait pas d’impact immédiat puisque mon workload existe déjà sur le service.
Pour autant, ça a été le déclic pour me pousser à faire la migration, qui m’aura pris une bonne demi-journée.
Voici comment j’ai procédé :
- Créer un repository sur mon instance Gitea
- Pusher ma copie locale sur ce nouveau repository
- Demander à Claude Sonnet de convertir mon
buildspec.yamldans le format GitHub Actions - Constater que ça fonctionne parfaitement du premier coup
- Se dire qu’il est temps d’optimiser un peu les choses, car télécharger toutes les dépendances à chaque build, c’est quand même sacrément stupide
- Vouloir trop en faire et partir sur une image Alpine
- Obtenir la bonne image au… douzième essai
- Valider et profiter
Bluffé par ce qu’a produit Sonnet, j’ai malheureusement déchanté sur les points suivants quand j’ai voulu construire (et surtout utiliser) une image runner contenant Hugo/rsync/discord.sh pour avoir toutes mes dépendances immédiatement.
Le principal problème que j’ai eu était lié à l’usage de l’action checkout et comme j’ai trouvé peu d’infos sur le sujet, je m’autorise à faire un petit aparté sur le sujet.
Gitea Actions : OCI runtime exec failed: exec failed: unable to start container process: exec: “node”: executable file not found in $PATH: unknown
Solution : actions/checkout@v2 needs Node.js to work, adding it in the runner image should fix the issue (e.g. apk update && apk add nodejs for Alpine)
Je voyais bien que l’erreur parlait de node mais comme à aucun moment, je ne l’utilise dans ma pipeline, je pensais que c’est un autre type de node dont il était question.
D’autant plus que le README de checkout ne fait pas référence à des requirements/dépendances.
Est-ce parce que dans GitHub ça fonctionne différemment ?
Il faudrait que j’essaie.
Ensuite, les échecs classiques quand on part sur du Alpine, c’est qu’il faut installer les paquets même les plus basiques et quand on se décide un peu tardivement à tout tester en local avant de builder à distance pour voir le résultat et découvrir qu’on a encore oublié une dépendance.
Maintenant, c’est bon, ça fonctionne aussi bien qu’avant, et même mieux puisqu’il n’y a plus de phase de pré-build, grâce à ma superbe image runner.
En bonus, j’ai conditionné le déclenchement de la pipeline à la branche main, ce que je n’avais pas fait sur CodeBuild et qui m’obligeait à ne pas pousser les autres branches, pour éviter de tout flinguer.
Oui, ce que j’avais fait sur CodeBuild c’était vraiment le strict minimum.
Les cordonniers, tout ça, tout ça…
J’en ai également profité pour faire de même pour quelques autres petits projets.
La suite, c’est probablement de me pencher sur la gestion du cache, pour éviter que le rsync ne se retrouve à tout transférer à chaque build.