Hugo on Zwindler's Reflection

Refonte de la page Conférences : data-driven avec Hugo

Fri, 13 Mar 2026 20:00:00 +0100

Grosse refonte de ma page “Conférences” qui était un bazar sans nom, dans lequel j’avais aussi mélangé les podcasts, les publications écrites, etc. Maintenant tout est présenté avec des “cartes”, et bien séparé en 3 pages distinctes.

Tous les fichiers sources (YAML, layouts Hugo, CSS) sont disponibles dans /misc/conferences-refonte/ si vous voulez reproduire ou vous en inspirer.

Le problème

Ma page Conférences était un gros fichier Markdown monolithique. Talks, podcasts, publications, orga : tout mélangé dans des listes à puces, avec des doublons, et de plus en plus pénible à maintenir (surtout depuis le passage en multi-langue FR/EN).

L’approche : données + layouts + CSS

Plutôt que de continuer à maintenir du Markdown, je suis passé en data-driven, comme je l’ai fait pour mon side project “101 ways to deploy Kubernetes” :

Données dans des fichiers YAML (data/)
Présentation dans des layouts Hugo custom (layouts/page/)
Style dans des CSS dédiés (static/css/)
Pages Markdown réduites au strict minimum (front matter uniquement)

Et au passage, j’ai découpé une page fourre-tout en trois : Conférences, Podcasts & Lives, Publications.

Les données YAML

`data/conferences.yaml`

Le plus gros fichier. L’idée clé : un talk (sujet unique) peut être présenté à plusieurs events. Fini la duplication.

talks:
 - id: k8s-scheduling
 title:
 fr: "Limits, Requests, QoS, PriorityClasses, ..."
 en: "Limits, Requests, QoS, PriorityClasses: ..."
 cospeaker: "Quentin Joly"
 slides: "/talks/2025-lrqppobcqvpsslsdk/..."

events:
 - talk: k8s-scheduling  # référence l'id du talk
 event: "DevoxxFR 2026"
 date: 2026-03-22
 type: conference
 - talk: k8s-scheduling
 event: "TNT 26"
 date: 2026-02-12
 type: conference
 video: "https://www.youtube.com/watch?v=..."

organizer:
 - description:
 fr: "Membre de l'équipe d'organisation du Meetup CNCF Bordeaux"
 current: true

Les titres sont bilingues (FR/EN), Hugo sélectionne la bonne langue automatiquement. Les fichiers data/podcasts.yaml et data/publications.yaml suivent le même principe (voir les fichiers sources).

Les pages Markdown minimalistes

L’ancienne page content/page/conferences.md faisait 100+ lignes avec le contenu complet. Voici la nouvelle :

---
title: 'Conférences'
authors:
 - zwindler
type: page
layout: conferences
date: 2022-03-14T18:00:00+00:00
menu:
 main:
 weight: -40
 params:
 icon: messages
toc: false
---

Le point important, c’est layout: conferences dit à Hugo d’utiliser layouts/page/conferences.html au lieu du layout par défaut. Même chose pour podcasts et publications.

Le layout Hugo

Le layout charge les données YAML, calcule des stats, et génère du HTML. Si vous avez déjà manipulé du GoTemplate (helm notamment), ça vous semblera facile à comprendre.

Chargement et indexation des talks :

{{- $data := .Site.Data.conferences -}}
{{- $talks := dict -}}
{{- range $data.talks -}}
 {{- $talks = merge $talks (dict .id .) -}}
{{- end -}}

Compteur dynamique ex. combien de fois un talk a été présenté :

{{- $count := 0 -}}
{{- $talkId := .id -}}
{{- range $data.events -}}
 {{- if eq .talk $talkId -}}
 {{- $count = add $count 1 -}}
 {{- end -}}
{{- end -}}
<p class="talk-card-count">Présenté {{ $count }}x</p>

Événements groupés par année, les 2 plus récentes dépliées, le reste en archive pliable via <details> :

{{- range $i, $year := $sortedYears -}}
 {{- if lt $i 2 -}}
 <details class="year-group" open>
 {{- else -}}
 <details class="year-group">
 {{- end -}}

Les événements à venir (date dans le futur) reçoivent automatiquement un badge “à venir”. Les layouts complets sont dans les fichiers sources.

Le CSS : des cartes partout

Le design repose sur des cartes CSS grid, avec des badges colorés par type (conf, meetup, BBL), du responsive, et un support dark mode. L’essentiel :

.talks-grid {
 display: grid;
 grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
 gap: 1.2rem;
}

.talk-card {
 background: var(--card-background);
 border-radius: 10px;
 padding: 1.2rem;
 transition: border-color 0.2s ease, box-shadow 0.2s ease;
}

.type-conference { background: #dbeafe; color: #1e40af; }
.type-meetup { background: #dcfce7; color: #166534; }
.type-bbl { background: #fef9c3; color: #854d0e; }
.type-upcoming { background: #fee2e2; color: #991b1b; }

Les CSS complets gèrent aussi le dark mode et les breakpoints mobile. Ils sont dans les fichiers sources.

Bilan

Aspect	Avant	Après
Pages	1 fourre-tout	3 spécialisées
Données	Markdown libre	YAML structuré
Duplication	Oui	Non (relation talk → events)
Stats	Aucune	Automatiques
Design	Listes à puces	Cartes + badges
Multi-langue	Copier-coller	Titres FR/EN dans le YAML
Archives	Tout d’un bloc	Années pliables

C’était un gros morceau : 19 fichiers et ~2400 lignes (une grosse partie du taf, en particulier la traduction markdown => YAML et le CSS, a été faite par un LLM), mais la logique est simple : données dans YAML, présentation dans les layouts, style dans le CSS. Hugo fait le lien au build, sans JavaScript.

Pour ajouter un nouveau talk maintenant, il me suffit d’ajouter une entrée dans data/conferences.yaml et les stats se mettent à jour toutes seules.

Avouez que c’est quand même plus propre qu’un copier-coller dans plusieurs fichiers Markdown :).

De F à A+ sur HTTP Observatory : sécuriser les headers de mon blog Hugo

Sat, 21 Feb 2026 10:00:00 +0200

Après l’optimisation des performances du blog (AVIF, pré-compression), j’étais super content de moi. 🥳

Mais c’était sans compter sur Antoine Caron, qui est venu (à très juste titre) me chatouiller sur un autre aspect que j’avais ignoré, le rapport Mozilla Observatory…

J’ai donc lancé un scan Mozilla HTTP Observatory sur mon blog et le résultat était : F.

Cool, je peux pas faire pire.

Le déclic

En relisant l’article de Julien sur codeka.io, qui a aussi parlé avec Antoine, a aussi un blog statique avec Hugo, MAIS qui lui avait fait le taf, j’ai réalisé que c’était à la fois important et peut-être pas si compliqué à corriger.

Julien y détaille les headers de sécurité à ajouter sur un site Hugo, avec des exemples pour Caddy. Moi je suis sur nginx, mais le principe est le même.

Note : si ça vous intéresse, les liens des épisodes précédents sur l’infra du blog sont ici :

Ça bouge pas mal sur le blog ! (2019) - De 5s à 1s en virant Wordpress pour Hugo
Ça bouge encore sur le blog (2025) - Nettoyage massif, retour auto-hébergé
Automatiser son site Hugo sans Github Action ou Vercel - Le setup nginx + webhook actuel
Optimisation webperf : AVIF et pré-compression - Le round précédent (focus sur les images)

Ce que teste HTTP Observatory

HTTP Observatory vérifie une série de headers HTTP que votre serveur devrait envoyer pour protéger vos visiteurs. Les principaux :

Strict-Transport-Security (HSTS) : force le navigateur à toujours utiliser HTTPS
Content-Security-Policy (CSP) : contrôle quelles ressources le navigateur peut charger (scripts, styles, images, iframes…)
X-Content-Type-Options : empêche le navigateur de “deviner” le type MIME des fichiers
Referrer-Policy : contrôle les informations de provenance envoyées aux sites tiers
X-Frame-Options / frame-ancestors : empêche l’inclusion de votre site dans une iframe (clickjacking)

Sur un blog statique, on pourrait se dire que ce n’est pas critique. Pas de base de données, pas de sessions utilisateur, pas de formulaires sensibles. Mais ces headers protègent quand même contre des attaques réelles :

Un script injecté (XSS) pourrait rediriger vos lecteurs vers un site malveillant
Sans HSTS, un attaquant sur un Wi-Fi public pourrait intercepter la connexion initiale en HTTP
Sans frame-ancestors, quelqu’un pourrait inclure le blog dans une iframe piégée

Bref, même pour un blog statique, ça peut valoir le coup de faire l’effort, a minima pour s’habituer aux bonnes pratiques.

Étape 1 : les headers “faciles”

Le piège nginx : add_header et l’héritage

La première chose, c’est que je suis tombé dans un piège classique avec mon nginx. Je l’ignorais, mais les directives add_header dans un bloc location écrasent (et ne complètent pas) celles du bloc server parent.

Ça veut dire que si vous avez un add_header Cache-Control dans une location (c’était mon cas), tous vos headers de sécurité définis au niveau server disparaissent pour cette location. J’ai pété un plomb pendant quelques minutes à reload / restart en boucle sans comprendre.

La solution : créer un fichier snippet et l’inclure partout.

cat > /etc/nginx/snippets/security-headers.conf << 'EOF'
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "..." always;
EOF

Puis dans la config nginx :

server {
 # Headers de sécurité au niveau server
 include /etc/nginx/snippets/security-headers.conf;

 # Cache des assets statiques
 location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|svg|webp|avif)$ {
 expires 1y;
 add_header Cache-Control "public, immutable";
 # OBLIGATOIRE : ré-inclure les headers ici !
 include /etc/nginx/snippets/security-headers.conf;
 }

 location ~* \.html$ {
 expires 1h;
 add_header Cache-Control "public, must-revalidate";
 include /etc/nginx/snippets/security-headers.conf;
 }
}

HSTS, X-Content-Type-Options, Referrer-Policy

Ces trois-là sont les plus simples à ajouter et “ne cassent rien” :

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

HSTS avec max-age=63072000 (2 ans) et preload permet à terme (pas encore fait) de s’inscrire sur la HSTS preload list. Le navigateur refusera même la toute première connexion HTTP initiale.
nosniff empêche les navigateurs d’interpréter un fichier texte comme du JavaScript.
strict-origin-when-cross-origin envoie l’URL complète en referrer pour les requêtes same-origin, mais seulement l’origine (domaine) pour les requêtes cross-origin.

Étape 2 : Content-Security-Policy (la vraie difficulté)

La CSP est un header puissant et a priori complexe. C’est lui qui rapporte le plus de points sur Observatory, mais c’est aussi lui qui peut tout casser si on va trop vite.

Le principe : vous déclarez au navigateur exactement quelles ressources votre site a le droit de charger (scripts, styles, images, iframes, fonts…) et depuis quelles origines. Tout le reste est bloqué. C’est la meilleure défense contre le XSS, parce que même si un attaquant arrive à injecter un <script> dans votre HTML, le navigateur refusera de l’exécuter s’il n’est pas dans la liste autorisée.

Le revers de la médaille : si vous oubliez une ressource légitime dans votre CSP, elle sera bloquée et votre site casse silencieusement : un script qui ne charge plus, une font qui disparaît, une iframe vide. Il faut donc faire un inventaire exhaustif avant de verrouiller.

Je me suis fait épauler par un LLM (Opus 4.6) pour les modifs à réaliser et on a fait plusieurs passes jusqu’à ce que tout fonctionne.

Inventaire des ressources externes

Avant d’écrire la CSP, il faut faire l’inventaire de tout ce que le site charge. Voilà une petite synthèse de mon pote Claudio :

Type	Ressource	Origine
Script	GoatCounter analytics	`https://gc.zgo.at/count.js`
Script	Umami analytics	`https://cloud.umami.is/script.js`
Connect	GoatCounter API	`https://blogzwindler.goatcounter.com`
Connect	Umami API	`https://api-gateway.umami.dev`
Script	De mon thème ‘stack’ - vibrant.js (couleurs d’images)	`https://cdn.jsdelivr.net`
Script	De mon thème ‘stack’ - PhotoSwipe (lightbox images)	`https://cdn.jsdelivr.net`
Style	De mon thème ‘stack’ - PhotoSwipe CSS (lightbox)	`https://cdn.jsdelivr.net`
Style	De mon thème ‘stack’ - CSS du thème	local (`'self'`)
Font	Luciole	locale
Frame	Widget Deezer (inclu dans un seul article 😖)	`https://widget.deezer.com`
Image	data: URIs (SVGs inline)	`data:`
Form	Mailchimp (abonnement newsletter)	`https://zwindler.us15.list-manage.com`

Le problème des scripts d’analytics externes

Avec une CSP comme script-src 'self' https://gc.zgo.at https://cloud.umami.is, je devais soit :

Faire confiance à ces CDN -> si le CDN est compromis, le script malveillant s’exécute sur mon blog. Nope.
Ajouter des hashes SRI (Subresource Integrity). Problème : ces scripts peuvent changer côté serveur sans prévenir, ce qui casserait le hash.

J’ai choisi une troisième voie : télécharger les scripts à chaque build et les servir localement.

# Dans mon petit script blog_refresh.sh, avant le hugo --minify
mkdir -p static/js
curl -sf --max-time 10 https://gc.zgo.at/count.js -o static/js/count.js \
 || echo "WARN: failed to download GoatCounter script"
curl -sf --max-time 10 https://cloud.umami.is/script.js -o static/js/umami.js \
 || echo "WARN: failed to download Umami script"

Et dans le template Hugo :

<script data-goatcounter="https://blogzwindler.goatcounter.com/count"
 async src="/js/count.js"></script>
<script defer src="/js/umami.js"
 data-website-id="3d8f0ea9-..."></script>

Est-ce que c’est “tricher” ?

Une fois que j’avais fait la modif, je me suis demandé : est-ce qu’héberger les scripts localement à chaque build ne contourne pas l’esprit des vérifications d’Observatory ? Sur ce point précis j’ai un petit doute, n’étant pas expert sur ces points là. J’ai demandé à un LLM qui m’a dit que non, mais je veux bien un avis tiers.

Dans tous les cas, ça semble être l’approche recommandée par la documentation GoatCounter pour les sites avec une CSP stricte.

Supprimer `unsafe-inline` de `script-src`

Observatory pénalise fortement 'unsafe-inline' dans script-src. Et c’est normal, car c’est la porte ouverte au XSS : n’importe quel script injecté dans le HTML s’exécute.

Le problème : mon thème Hugo (hugo-theme-stack) générait 4 scripts inline :

Color scheme init — lit le localStorage pour appliquer le thème clair/sombre avant le premier rendu
Color scheme detection — détecte la préférence système (prefers-color-scheme: dark)
Language switcher — le sélecteur de langue <select onchange="window.location.href=this.selectedOptions[0].value"> dans la sidebar, qui est un attribut d’événement inline (script-src-attr)
Font loader — charge la CSS de la font Luciole dynamiquement

Luciole: A typeface for visual impairment

Pour chacun, j’ai extrait le code dans un fichier .js externe dans static/js/ et remplacé le script inline par une balise <script src="...">.

Par exemple, pour le color scheme, le thème avait dans layouts/partials/head/colorScheme.html :

<script>
 (function() {
 const colorSchemeKey = 'StackColorScheme';
 if(!localStorage.getItem(colorSchemeKey)){
 localStorage.setItem(colorSchemeKey, "auto");
 }
 })();
 /* ... */
</script>

Que j’ai remplacé par un override de template Hugo :

{{- /* Override: external JS file instead of inline (CSP compliance) */ -}}
<script src="/js/color-scheme.js"></script>

Avec le contenu correspondant dans static/js/color-scheme.js. Hugo permet de surcharger n’importe quel template du thème en plaçant un fichier au même chemin dans le dossier layouts/ du projet.

Pour le language switcher, même approche : j’ai surchargé layouts/partials/sidebar/left.html pour retirer l’attribut onchange du <select> et ajouté un id="language-select", puis créé un fichier static/js/language-switcher.js :

(function () {
 var select = document.getElementById('language-select');
 if (select) {
 select.addEventListener('change', function () {
 window.location.href = this.selectedOptions[0].value;
 });
 }
})();

Note importante : il m’a fallu plusieurs allers-retours avec la console du navigateur (F12 -> Console) avant de trouver la totalité des violations CSP. Chaque correction en révélait de nouvelles, il fallait bien regarder tous les différents types de pages sur le blog (pas juste la page d’accueil et les posts), et certaines erreurs affichées dans la console venaient en fait d’extensions navigateur (typiquement les gestionnaires de mots de passe comme Bitwarden, dont le bootstrap-autofill-overlay.js génère des violations style-src-elem) et non du site lui-même. Il faut donc bien distinguer les erreurs du site de celles injectées par les extensions.

Supprimer `unsafe-inline` de `style-src`, la suite

Même logique pour les styles. J’avais quatre sources d’inline CSS :

Un bloc <style> dans custom.html — les CSS custom properties pour ma font Luciole
Des attributs style="" sur les badges de catégories — background-color: #2a9d8f; color: #fff;
Un attribut style="enable-background:..." sur un SVG (export Adobe Illustrator)
Des attributs style="" dans le formulaire Mailchimp du footer — display:none et un positionnement off-screen pour le honeypot anti-spam

Le <style> bloc : déplacé dans assets/scss/custom.scss, le fichier de personnalisation SCSS prévu par le thème.

/* Font family CSS custom properties */
:root {
 --article-font-family: "Luciole";
 --base-font-family: "Luciole";
 /* ... */
}

Les badges de catégories : toutes mes catégories utilisent les mêmes couleurs (#2a9d8f / #fff), définies dans le front matter de chaque _index.md. Le thème les injectait en style="" via le template article/components/details.html. J’ai surchargé ce template pour retirer le style inline et ajouté une règle CSS dans custom.scss :

.article-category a {
 background-color: #2a9d8f;
 color: #fff;
}

Le SVG : j’avais un SVG que j’avais ajouté à la main (un petit Robot mignon pour mon “AI Manifesto”) avec enable-background, qui est un attribut SVG 1.1 déprécié. Je l’ai simplement supprimé du fichier SVG source, sans impact visuel.

Le formulaire Mailchimp : le code HTML Mailchimp utilise style="display:none" pour masquer les divs de feedback et style="position: absolute; left: -5000px;" pour le champ honeypot (pour les robots qui s’inscrivent à ma newsletter 🤔). J’ai remplacé tout ça par des classes CSS dans custom.scss :

#mce-error-response,
#mce-success-response {
 display: none;
}

.mce-honeypot {
 position: absolute;
 left: -5000px;
}

La CSP finale

Après tous ces changements, plus aucun script ni style inline sur le site. La CSP peut donc être stricte :

default-src 'none';
script-src 'self' https://cdn.jsdelivr.net;
style-src 'self' https://cdn.jsdelivr.net;
img-src 'self' data:;
connect-src 'self' https://blogzwindler.goatcounter.com https://api-gateway.umami.dev https://cdn.jsdelivr.net;
font-src 'self';
frame-src https://widget.deezer.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self' https://zwindler.us15.list-manage.com;
manifest-src 'self';
media-src 'self'

Points notables :

default-src 'none' : par défaut, rien n’est autorisé. Chaque type de ressource doit être explicitement listé. C’est la politique la plus restrictive.
Pas de unsafe-inline nulle part : ni dans script-src, ni dans style-src
frame-ancestors 'none' remplace X-Frame-Options: DENY (plus moderne)
cdn.jsdelivr.net dans script-src, style-src ET connect-src : le thème charge vibrant.js (JS avec SRI), les CSS de PhotoSwipe (lightbox d’images) et les source maps associées depuis ce CDN
form-action autorise Mailchimp pour le formulaire d’abonnement dans le footer

Au final, de nombreux morceaux du thème de mon blog ont du être réécrit / overridés. Je suis un peu gêné d’avoir du en arriver là, mais c’était le prix à payer pour une note maximale 😂.

Nettoyage bonus : Mailchimp

En faisant l’inventaire des ressources externes, j’ai découvert un vieux widget Mailchimp dans la sidebar qui chargeait du CSS et du JavaScript depuis chimpstatic.com. Je ne l’utilisais plus : supprimé. Le formulaire d’abonnement dans le footer des articles a été gardé, mais nettoyé de ses style="" inline (voir plus haut).

Résultat final

De F (0/100) à A+ (125/100). Tous les tests sont verts.

Un grand merci à Antoine pour sa patience avec les débutants naïfs comme moi 😂 et ses super talks !

J'ai donné 1 heure à des agents Copilot pour migrer un site de Bloggrify à Hugo

Tue, 02 Dec 2025 18:00:00 +0200

TL;DR pour les pressés

J’ai fait migrer un site statique de Bloggrify vers Hugo par GitHub Copilot Agent.

Les règles ? Une heure chrono, quelques tâches mais jamais plus de 2 en parallèle pour que l’humain conserve une charge mentale acceptable.

Spoiler : l’IA est meilleure que moi en bash (je le savais déjà, c’est pas très dur), correcte pour le CSS (après 2-3 essais), et dangereusement créative sur les parties rédigées, même celles qui sont déjà bonnes (askip j’ai été speaker à la KubeCon EU 2024… j’y étais même pas !).

Point fort inattendu : Playwright qui fait des screenshots automatiques à chaque modif. Un vrai game changer dans ce genre de cas d’usage IMO.

Le contexte : pourquoi se faire mal ?

Si vous suivez le blog, vous savez que j’ai publié un livre (Kubernetes : 50 solutions pour les postes de développement et les clusters de production), et vous savez aussi qu’il y a un site séparé pour la promotion du livre : 50ndk.zwindler.fr.

A l’époque je voulais en profiter pour tester un truc nouveau, j’avais donc testé Bloggrify (un générateur de sites statiques écrit par Hugo Lassiège). Sauf qu’à l’usage, je suis perdu dans l’écosystème JS, et je me suis dit que j’allais le migrer vers Hugo avec le thème Stack (exactement le même que ce blog).

Dans les deux cas, c’est des générateurs de sites statiques avec le contenu en markdown. Théoriquement, c’est pas compliqué à faire.

Mais au lieu de le faire manuellement, j’ai décidé de me lancer un petit défi : tout déléguer à des agents GitHub Copilot, en me limitant à 1 heure et en maintenant une charge mentale acceptable (comprendre : pas plus de 2 tâches en parallèle, sinon mon cerveau explose).

J’ai donc ouvert Copilot, choisi Claude Sonnet 4.5 (car Gemini 3 Pro, qui venait de sortir, était cassé) et je lui ai donné d’un côté le dépôt de 50ndk, de l’autre le dépôt de blog.zwindler.fr et je lui ai donné un court prompt du type :

Ce site a été créé à partir d’un outil appelé bloggrify. J’aimerai migrer tout le contenu markdown / images de ce blog vers un blog statique de type Hugo, que je maitrise mieux. Bases toi sur @zwindler/blog.zwindler.fr pour la structure et le thème à utiliser

Phase 1 : La migration technique (15 minutes)

Ce qui a marché tout seul

Première bonne impression : la migration de base a pris 15 minutes. Copilot Agent a :

Converti la structure Bloggrify vers Hugo
Installé Hugo
Mis en place le thème Stack
Créé un workflow automatisé complet avec :
- Build du site
- Démarrage d’un serveur local
- Capture d’écran Playwright 📸 (on y reviendra, c’est LE truc génial)
Nettoyer tout ce qui avait un rapport avec Bloggrify / Javascript

Résultat : un site fonctionnel du premier coup. Mais pas parfait !

Les premiers soucis (détectés par l’humain… aka moi)

En regardant le screenshot généré, j’ai repéré deux trucs bofs :

Menu “Archives” affiché en double dans la partie gauche
Des catégories inutiles. En effet, dans le site 50ndk, je n’avais pas utilisé de catégories, seulement des tags. Or le thème Stack met beaucoup en avant les catégories, et c’était moche.

L’agent n’avait rien détecté car en soi, c’est OK, ça fonctionne. Normal : c’est du visuel, et il faut un humain pour dire “euh, là c’est moche”.

Les corrections (7 min + 4 min)

Une fois que je lui ai signalé les problèmes, l’agent a :

su diagnostiquer précisément la cause du menu dupliqué (défini à la fois dans hugo.yaml ET dans le frontmatter de content/page/archives/index.md)
corrigé en ~7 minutes
réglé le problème des catégories en ~4 minutes

L’agent est bon pour débugger… une fois que l’humain a détecté le bug :

Agent génère
Screenshot Playwright
Humain vérifie puis formule un feedback
Agent corrige
et on itère comme ça

Sans Playwright, j’aurais dû manuellement builder, lancer le serveur, rafraîchir le navigateur à chaque itération. L’automatisation de cette boucle, c’est un game changer absolu.

Phase 2 : La page “À propos” (20-25 min, et des “““hallucinations”””)

Ce qui a bien commencé

Deuxième tâche : améliorer la page “À propos”. L’agent a :

Analysé le contexte (mes articles, ma page whoami sur blog.zwindler.fr)
Pondu une première version correcte, bien structurée
Su ajouter des images quand je lui ai demandé
Été capable de faire des ajustements rapides sur demande (“double la longueur”) ou seul, “j’au corrigé la faute de frappe ‘20240’ → ‘2024’”)

Jusque-là, RAS. Puis…

Quand l’IA devient romancier

Après quelques itérations, le LLM a commencé à réécrire certaines parties qui étaient bonnes.

Genre, carrément :

“Participation à la KubeCon EU 2024 en tant qu’organisateur/speaker”
Changé le nom du livre et l’éditeur
…

La supervision humaine pour la vérification factuelle est indispensable, surtout sur du contenu biographique. J’ai dû corriger plusieurs fois en mode “non, cette partie est fausse”.

Phase 3 : Les tâches techniques (et là, ça roule)

Ajout de scripts de tracking

Tâche : intégrer Hakanai + Umami sur toutes les pages.

L’agent a :

Créé un partial template dans layouts/partials/
Inclus automatiquement dans le layout principal
Placé les scripts au bon endroit (avant </body>)

C’est ce que j’aurais fait aussi. Nickel, RAS.

Optimisation d’image (succès… mais… pourquoi ???)

Je lui ai donné la tâche complètement débile de réduire ma photo de profil, qui était extrêmement grosse (j’avais vraiment été bourrin sur la version Bloggrify…)

Tâche : réduire avatar.jpg de 1.3 Mo à ~250 Ko.

L’agent l’a fait. Techniquement, ✅. J’aurais été beaucoup plus rapide à le faire manuellement (quelques secondes avec un outil d’optimisation d’images). Mais j’ai voulu pousser l’expérience jusqu’au bout et tester les limites de l’agent sur des tâches “simples” (pour un humain) comme celle là.

Entre le coût cognitif de formulation de la demande, le temps d’attente et l’énergie consommée pour lancer un pauvre resize de JPEG par rapport à une action manuelle directe, c’est clairement pas le meilleur usage. Mais ça fonctionne.

Mise en page des images (page “À propos”) - CSS/Layout complexe

Tâche : faire “épouser” le texte autour des images (float layout) + définir hauteur à 200px.

L’agent a proposé plusieurs itérations avant d’arriver à une version qui fonctionnait. Les tâches CSS/layout complexes nécessitent souvent plusieurs itérations. L’agent propose des solutions techniquement valides mais qui peuvent entrer en conflit avec les styles existants du thème. La validation visuelle via screenshot est indispensable.

Widget “Commander le livre” dans la barre de droite

Tâche : ajouter un widget dans la sidebar avec liens vers vendeurs (Eyrolles, Cultura, Amazon, Fnac).

Là encore, il a fallu plusieurs tentatives pour avoir un truc qui fonctionne sur Hugo / mon thème. La première itération était KO. Il a fallu qu’il comprenne qu’il fallait faire un widget personnalisé (j’ai eu à en faire aussi, j’aurais pu le guider s’il n’avait pas trouvé seul).

L’agent a créé :

layouts/partials/widget/book-links.html
HTML + CSS inline cohérent avec le thème Stack
Modification de hugo.yaml pour référencer book-links

Résultat final : un widget affiché avec les 4 liens avec en bonus que je n’avais pas demandé un effet hover (jamais j’aurais su faire ça).

Comportement bizarre : PR ou commit direct ?

Sur ce projet, la branche main n’était pas protégée (oui c’est pas bien, nia nia nia). Donc selon les cas, l’agent s’est mis, soit à créer des PRs, soit à commiter directement sur main (avec mon accord).

Je n’ai pas réussi à bien comprendre comment il arrivait à déterminer que dans tel cas il fallait une PR, et dans tel autre, un simple commit suffisait. Je n’ai pas creusé, mais ça m’intrigue un peu (si quelqu’un a l’explication).

Dans tous les cas, cette question est probablement un peu bêbette, le mieux, c’est de protéger main.

Un PaaS, ça aide

Petit point bonus qui a bien aidé pour cette migration, le fait que le site ait été hébergé sur Clever Cloud (sur un PaaS plus généralement, car ça aurait probablement été vrai sur d’autres PaaS).

Dans ce cas précis, Clever a su détecter qu’on était passé de JS à Hugo sans que je n’aie rien à faire. Ça, plus le fait que les builds étaient très rapides (30 secondes entre le commit et la mise à dispo de la nouvelle version), ça m’a permis d’itérer extrêmement vite.

Si j’avais dû m’occuper de l’infra pour migrer le tooling sur une VM, ou en monter une autre, cette expérimentation ne serait pas allée aussi loin.

Conclusion

La découverte majeure de l’expérimentation, c’est sans aucun doute possible le fait que Copilot utilise Playwright pour tester, et quand il est content de son résultat, pouvoir afficher à l’humain une capture d’écran de ce qu’il pense être valide.

Ça s’est révélé extrêmement utile dans le cadre de ce projet. À de multiples reprises, sans Playwright, j’aurais dû manuellement builder, lancer le serveur, rafraîchir le navigateur avant de voir un truc cassé ou moche, à chaque itération. L’automatisation de cette boucle de feedback visuelle est un game changer pour la productivité.

Ça ne sera pas universel, mais j’ai trouvé que 2 tâches simultanées (3 à la rigueur) c’était une bonne limite pour garder suffisamment en tête toutes les tâches en cours et être efficace pour review quand le LLM avait “fini”. J’aurais pu faire plus de choses mais j’ai eu peur d’être moins alerte et de laisser passer plus de bêtises.

Cette expérimentation d’environ 1 heure a démontré que GitHub Copilot Agent est particulièrement efficace pour :

Les migrations techniques (gain de temps massif : ~15 min pour Bloggrify → Hugo, j’aurais mis plus, c’est sûr)
Le debugging assisté (une fois le problème identifié par l’humain)

Cependant, il nécessite toujours une supervision humaine attentive, voire très attentive pour :

Les faits (ça sortait tellement de nulle part, cette réécriture du contenu alors que je lui demandais de rajouter des images ?!?)
Les décisions UX/Design et les validations visuelles (lui, si c’est moche il s’en fout, un peu comme un dev back qui fait du front)
Les tâches CSS/layout complexes (rarement bon du premier coup, mais en même temps j’aurais pas fait mieux)
Les architecture spécifiques de frameworks/thèmes (et en plus il t’engueule en te disant que c’est la faute de ton thème)

J’insiste une dernière fois, mais l’intégration de Playwright pour les screenshots automatiques crée une boucle de feedback visuel qui transforme radicalement l’expérience de développement avec les agents. Je ne me renseigne peut-être pas assez et peut-être que ça existe depuis longtemps, mais c’est vraiment LE truc qui m’a le plus convaincu dans ce use case.

Globalement satisfait, ça fait réfléchir. Je vous laisse admirer le résultat :

Ce blog est (enfin) multilingue

Thu, 06 Nov 2025 12:00:00 +0200

Une évolution qui s’imposait

Après 15 ans d’existence de ce blog, et probablement 6 avec Hugo, j’ai enfin activé le mode multilingue propre de Hugo.

Pourquoi maintenant ? Plusieurs raisons :

D’abord parce que Quentin m’a trollé…
Mon lectorat est principalement francophone, mais j’ai aussi des lecteurs anglophones qui arrivent sur des articles techniques spécifiques. Jusqu’à présent, tout était mélangé sur la page d’accueil.
Côté référencement, c’était probablement un peu le bazar. Avoir des articles en français et en anglais mélangés sans distinction claire, ce n’est probablement pas optimal pour les moteurs de recherche.

Maintenant, chaque langue a son espace :

blog.zwindler.fr → page principale en français (n’affiche plus les articles en anglais)
blog.zwindler.fr/en → version anglaise (uniquement les articles en anglais, une dizaine pour le moment)

URLs conservées

J’aurais pu tout flinguer côté anglais et réécrire toutes les URLs pour rajouter le “/en”. Ou rajouter des alias avec Hugo (feature bien pratique que j’utilise quand je me suis foiré sur le lien mais que je l’ai déjà partagé un peu partout).

Pour l’instant, les URLs existantes restent inchangées. Les articles déjà publiés en anglais gardent leur URL sans le /en/.

Je verrai pour les prochains articles comment je gère ça.

L’implémentation technique

Pour les curieux, Hugo propose deux façons de gérer le multilingue :

Translation by file name : ajouter .en ou .fr avant .md
Translation by content directory : séparer les contenus dans des dossiers distincts

J’ai opté pour la seconde option, plus claire à mon goût :

languages:
 en:
 contentDir: content-en
 languageName: English
 weight: 10
 fr:
 contentDir: content
 languageName: Français
 weight: 20

Je ne sais pas si ça fonctionne avec tous les thèmes “out of the box”, mais le miens (https://stack.jimmycai.com/) mettait en avant que c’était supporté, donc j’en déduis qu’il faut faire gaffe à ça.

Des traductions à venir (peut-être ?)

Dans les prochains jours ou semaines, je ferai probablement quelques traductions d’articles, dans les deux sens :

Anglais → Français : certains articles très techniques et niches (comme Recompile Mimir’s “MetaMonitoring” Grafana Dashboards for Kubernetes) pourraient être traduits en français (ou non, c’est quand même giga niche)
Français → Anglais : des articles qui marchent bien en français et qui pourraient intéresser un public anglophone plus large

Je ne me mets aucun objectif, ni aucune pression. Si je trouve qu’un article mérite d’être traduit et que j’ai le temps/l’envie, je le ferai. Sinon, tant pis !

L’important, c’est d’avoir sauté le pas.

N’hésitez pas à me faire vos retours si vous constatez des problèmes de navigation ou d’affichage, j’ai un peu fait ça à l’arrache lundi soir pendant le live des copains Cuistops !

Références

Documentation officielle Hugo - Multilingual Mode

Je réessaye les sites statiques (Bloggrify) chez Clever Cloud

Mon, 07 Jul 2025 09:00:00 +0200

Introduction

Pour celles et ceux qui suivent mes péripéties d’hébergement de blog, vous savez que j’ai une relation compliquée (le fameux “it’s complicated” sur Facebook) avec Clever Cloud. J’ai déjà écrit à ce sujet dans deux articles précédents :

Pour finalement abandonner Clever Cloud et revenir sur une VM IONOS que je gère moi-même (voir Ça bouge encore sur le blog).

Mais depuis, Clever Cloud a ajouté les apps statiques à son catalogue. Plus besoin de passer par un runtime Apache + PHP, ce qui était effectivement un peu overkill pour un site Hugo statique (et pas compatible avec l’offre Pico, donc fallait prendre au minimum Nano à ~7€ par mois).

Du coup, je me suis dit : pourquoi ne pas retenter l’expérience ?

Comme Julien Wittouck m’a devancé de 3 semaines et a fait un article sur l’hébergement de sites statiques avec Hugo via ce nouveau type d’app chez Clever Cloud, vous pouvez aller lire son post ici, je n’ai pas envie de faire la même chose.

Pour ce test, j’ai choisi d’utiliser un autre site que celui-ci : 50ndk.zwindler.fr, qui me sert pour faire la promotion de mon livre.

Il est actuellement hébergé sur GitHub Pages et utilise le moteur Bloggrify (un des projets d’Hugo Lassiège, quelqu’un que j’apprécie énormément dans l’écosystème tech français).

Le principe est globalement le même qu’avec Hugo, à quelques petites différences près. C’est un site statique généré tout pareil, mais c’est Nuxt sous le capot et ça va nous être utile. Il y a quelques petites différences aussi depuis mon dernier test de 2023 que je ne manquerai pas de souligner.

Les sources du site sont disponibles ici si vous êtes curieux / curieuse :

https://github.com/zwindler/50ndk

Prérequis

On pourrait aller créer l’application dans l’UI. Normalement, les “tuiles” Static, Linux et VLang sont disponibles à tout le monde depuis le 4 juillet. J’ai un petit accès anticipé (merci David) mais je n’en ai pas beaucoup profité 🙃 (occupé avec le livre). Grosso modo c’est comme les autres types d’Apps chez Clever, vous ne serez pas perdus.

Bon, en WebUI c’est bien mais c’est plus rigolo de le faire en CLI.

clever login
Opening https://console.clever-cloud.com/cli-oauth?cli_version=3.0.2&cli_token=xxxxxxxxxxxxx in your browser to log you in…
Login successful as Denis GERMAIN <denis@domain.org>

Euh, je vois 3.0.2 dans l’URL ??? Je ne suis pas à jour. Visiblement j’avais installé la CLI clever avec npm (je ne m’en souviens pas). Plus simple, il y a aussi des dépôts .deb (ou brew, autre selon votre distribution).

clever version
3.0.2
╭─────────────────────────────────────────╮
│ │
│ Update available 3.0.2 → 3.13.1 │
│ Run npm i -g clever-tools to update │
│ │
╰─────────────────────────────────────────╯

Un petit npm i -g clever-tools et ça va mieux :)

$ clever version
3.13.1

Configuration de l’app

Un petit clever create avec le type de l’app et c’est parti !

denis@coucou % clever create --type static
✓ Application 50ndk successfully created!
Type ⬢ Static
ID app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Org ID user_yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
Name 50ndk
Zone par
Next steps:
! Commit your changes first:
$ git add .
$ git commit -m "My changes"
→ Run clever deploy to deploy your application
→ Manage your application at: https://console.clever-cloud.com/goto/app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Note : si votre app est hébergée sur GitHub, vous pouvez rajouter aussi --github OWNER/REPO à la ligne de commande précédente. J’en parle plus tard, mais lisez tout avant de le faire.

Comme fin 2023, je vais avoir besoin de 2 machines différentes. Une qui va construire mon site statique, une qui va le servir. Et du coup, là comme je n’ai pas Apache, je peux avoir accès à une pico et économiser quelques euros à la fin de l’année :

$ clever scale --build-flavor M
App rescaled successfully
$ clever scale --flavor pico
App rescaled successfully

Dans mon test précédent avec Hugo+Clever, j’avais besoin de spécifier dans quel dossier le contenu statique doit être servi (et aussi quel dossier la machine qui construit doit partager avec la machine qui sert).

Dans le cas de Bloggrify, tout est dans .output/public. MAIS comme c’est du Nuxt, David m’a dit que je n’en avais pas besoin parce que Clever détecte automatiquement que c’est du Nuxt grâce au fichier nuxt.config.ts à la racine du projet.

Inutile donc de spécifier les variables CC_WEBROOT, CC_OVERRIDE_BUILDCACHE (pour pointer sur .output/public) CC_PRE_BUILD_HOOK et CC_BUILD_COMMAND (les commandes npm).

Plutôt une bonne surprise :).

Déploiement de l’application

À partir de là, on peut essayer de faire un premier déploiement à la main. Pour rappel, soit on envoie un commit sur le remote spécial créé par Clever (cf le message lors de la commande clever create), mais je vais préférer utiliser la commande clever deploy, déjà disponible en 2023 lors de mon premier test, car je l’utiliserai pour automatiser le workflow plus tard.

dgermain@dgermain-mac 50ndk % clever deploy
🚀 Deploying 50ndk
 Application ID app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 Org ID user_yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy

🔀 Git information
 ! App is brand new, no commits on remote yet
 Local commit aaaaaa [will be deployed]

La première partie du processus va donc lancer une machine de taille M dans le but d’accélérer un peu le temps de construction :

🔄 Deployment progress
 → Pushing source code to Clever Cloud…
 ✓ Code pushed to Clever Cloud
 → Waiting for deployment to start…
 ✓ Deployment started (deployment_zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz)
 → Waiting for application logs…
 ...

Clever va détecter tout seul que j’ai du Nuxt, lancer un npm install pour installer les prérequis pour Bloggrify, puis le npm run generate pour générer le code HTML statique.

[...]
2025-07-07T10:23:47.847Z Deploying commit ID defc0be02d44ace246127e11a17d4f359262ccfb
2025-07-07T10:23:47.847Z Nuxt.js configuration file detected
2025-07-07T10:23:47.847Z Running build command: npm i && npm run generate && mv .output/public cc_static_autobuilt
[...]
2025-07-07T10:24:48.809Z [nitro] ℹ Initializing prerenderer
2025-07-07T10:24:52.533Z [nitro] ℹ Prerendering 8 initial routes with crawler
2025-07-07T10:24:52.598Z [nitro] ├─ /robots.txt (17ms)
2025-07-07T10:24:52.841Z [nitro] ├─ /200.html (296ms)
2025-07-07T10:24:52.842Z [nitro] ├─ /404.html (297ms)
2025-07-07T10:24:52.964Z [nitro] ├─ /api/search (415ms)
2025-07-07T10:24:52.965Z [nitro] ├─ /sitemap.xml (417ms)
2025-07-07T10:24:52.965Z [nitro] ├─ /rss.xml (416ms)
2025-07-07T10:24:53.105Z [nitro] ├─ / (564ms)
[...]

Une fois le generate terminé, la machine de construction génère un artefact contenant notre site, et passe la main à la machine qui va servir le trafic :

2025-07-07T10:24:55.843Z ✔ You can now deploy .output/public to any static hosting!
2025-07-07T10:24:56.137Z Creating build cache archive…
2025-07-07T10:24:56.197Z build cache archive successfully created
2025-07-07T10:24:56.197Z No cron to setup
2025-07-07T10:24:56.213Z Uploading application build cache archive… file is 21M before compression.
2025-07-07T10:24:56.899Z 2025-07-07T10:24:56.899385Z INFO multipart_upload_lib::uploader: Uploaded part=1
2025-07-07T10:24:57.041Z 2025-07-07T10:24:57.041879Z INFO multipart_upload_lib::uploader: Completed the multipart upload
2025-07-07T10:24:57.350Z Done uploading build cache archive
2025-07-07T10:24:57.350Z Build succeeded in 1 minute and 14 seconds

11 secondes plus tard, le site de promotion de mon livre est déployé sur Clever Cloud

2025-07-07T10:25:28.425Z Serving static website from /cc_static_autobuilt
2025-07-07T10:25:28.425Z Launching 'static-web-server' on port 8080
2025-07-07T10:25:28.425Z No cron to setup
2025-07-07T10:25:28.425Z Successfully deployed in 0 minutes and 10 seconds

✓ Access your application: https://app-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.cleverapps.io
→ Manage your application: https://console.clever-cloud.com/goto/app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Ajouter un domaine

Comme chez tous les PaaS, il est évidemment possible d’ajouter un domaine de manière à ce que les requêtes entrantes n’aient pas besoin de se faire sur l’URL en cleverapps.io

% clever domain add 50ndk.zwindler.fr
Your domain has been successfully saved

Une fois le FQDN associé, il est possible d’ajouter un CNAME chez votre gestionnaire de nom de domaine :

Automatiser le `clever deploy`

Imaginons que je sois un fainéant ou que je n’aie pas envie d’installer clever CLI sur tous les postes où je travaille. Admettons que j’aie envie qu’une nouvelle version de mon site soit automatiquement déployée dès que je pousse un commit sur GitHub.

deploy-to-clever-cloud

Dans l’article Planifier les posts de mon blog Hugo sur Clever Cloud, j’avais exploré la piste d’un Cron pour redéployer régulièrement mon site, notamment pour que les posts publiés dans le futur soient postés “au bon moment”.

J’avais aussi trouvé une GitHub Action tierce de quelqu’un (47ng) qui a l’air très bien mais que je ne connais pas :

https://github.com/marketplace/actions/deploy-to-clever-cloud

J’ai testé, elle fonctionne, mais j’étais moyen chaud à l’époque de déléguer mes creds à Github (les fameuses variables CLEVER_TOKEN et CLEVER_SECRET affichées lors du clever login), qui en retour les aurait injecté à cette “action”.

Et ben ça tombe bien parce qu’il y a deux nouvelles pour répondre à ces problématiques.

preview par PR

La première, c’est qu’il existe plusieurs façons d’automatiser les déploiements avec Clever Cloud. Je ne sais pas si elle existait à l’époque, mais en tout cas je l’ai trouvée aujourd’hui ;-P.

On peut faire des environnements de preview par PR (depuis 2024) :

Je ne vais pas dans cet article aborder cette action qui permet de déployer des apps en préview par PR car je n’en ai pas du tout le besoin pour ce site secondaire. Cela dit, si jamais j’ai une grosse mise à jour avec breaking changes, ça pourra valoir le coup de jeter un œil.

Créer des tokens de CI

La seconde, c’est qu’il est possible de créer des tokens (là encore, je ne sais plus si c’était possible en 2023), qu’il sera possible de révoquer en cas de leak.

https://www.clever-cloud.com/developers/api/howto/#request-the-api

Et avec ces tokens, on peut se faire sa propre CI :

https://www.clever-cloud.com/developers/doc/ci-cd/custom-scripts/

Note : j’ai cependant l’impression qu’il n’y a pas encore de scope sur le token. Donc en termes de sécu, c’est mieux car je peux les révoquer, mais s’il y a un leak, on a accès à tout mon compte, pour l’instant (sauf si j’ai mal compris).

Déploiements depuis GitHub (ou GitLab)

Mais le plus simple ici, c’est d’utiliser une fonctionnalité de Clever qui existe depuis “toujours” mais dont j’ignorais l’existance : les déploiements via Github.

Si vous voulez utiliser cette fonctionnalité, il faudra par contre autoriser Clever Cloud à lister vos dépôts préalablement (ce qui peut être un problème pour vous), et vous ne pourrez plus pousser des commits avec clever deploy ou git push sur le git remote de clever (vous prendrez une erreur 401).

Clever Cloud provides a GitHub integration to deploy any repository hosted on GitHub to Clever Cloud

On configure ça grâce au --github de tout à l’heure !

A partir du moment où c’est fait, il n’y a rien à faire… le rebuild sera déclenché dès que je pousserai un nouveau commit sur ma branche Github :)

commit 788465fb980c09e597872a3b510ac44fdaa27d48 (HEAD -> main, origin/main, origin/HEAD)
Author: Denis GERMAIN <denis@example.com>
Date: Fri Jul 4 16:31:11 2025 +0200
test commit

Note : on peut spécifier quelle branche on veut envoyer en prod dans les paramètres de l’application :

Conclusion

Clever Cloud a énormément bougé ces derniers mois, avec beaucoup de nouvelles apps, de nouvelles fonctionnalités (la plus grosse étant Materia, ainsi que tout le travail autour de l’IA).

Les static apps (et Linux, et V) pourraient presque paraître anecdotiques, mais couplées aux autres améliorations (tokens, Grafana managé avec les stats), ce n’est pas le même produit qu’en 2023.

C’est cool à voir :)

Planifier les posts de mon blog Hugo sur Clever Cloud

Mon, 29 Jan 2024 06:00:00 +0200

Suite de la migration

Fin décembre, j’ai migré ce blog sur Clever Cloud.

Cependant, David Legrand m’a fait remarquer que je n’avais plus de méthode pour planifier mes posts.

Depuis quelque temps, je poste à flux tendu donc ça ne m’a pas encore gêné (j’écris un post, je le rends public dans la foulée) mais c’est vrai qu’il me manque cette possibilité par rapport à précédent mon hébergement (une VM).

Cependant, il existe une solution sur Clever Cloud pour le faire. David en a d’ailleurs écrit un petit article sur son blog perso, adapté pour “Astro” son générateur de site statique.

Je vais donc faire pareil pour mon propre blog avec Hugo.

Adaptations

Repartons donc d’où j’en étais au post précédent. Nous avons un blog avec Hugo qui se déploie quand on fait des clever deploy (ou des commits sur le git remote de clever).

La première chose qu’on va devoir faire, c’est récupérer un token. En effet, c’est notre blog qui va déclencher de lui même les redéploiements, on va donc devoir lui donner de quoi s’authentifier.

Si vous n’avez pas de token sous la main, on peut en retrouver un en faisant clever login depuis un terminal, comme je l’expliquais dans l’article précédent.

Et on va rajouter le TOKEN dans la liste des variables d’environnement de notre app :

$ clever env set CC_SECRET "aaaaaaaaaaaaaaaaaaaaaaaaaa"
$ clever env set CC_TOKEN "aaaaaaaaaaaaaaaaaaaaaaaaaa"

A partir de là on va créer plusieurs fichiers. D’abord, un script qui va déclencher ce fameux redéploiement :

cat > clever_rebuild.sh << EOF
#!/bin/bash -l
clever link ${APP_ID}
clever restart --quiet --without-cache
EOF
chmod +x clever_rebuild.sh

Ensuite, je vais créer un fichier qui sera lu par clever-cloud et qui va déclencher ce redéploiement aux heures où je publie mes posts planifiés (le matin, un peu avant 9h) :

mkdir clevercloud
echo '["00 08 * * * $ROOT/clever_rebuild.sh"]' > clevercloud/cron.json

Attention aux petites blaguounettes de timezone. Comme tous sysadmins qui se respectent, les gens de clever utilisent le temps UTC sur leurs serveurs (moi aussi). Cependant, ça nécessite une petite gymnastique intellectuelle si jamais vous n’utilisez pas aussi le temps UTC dans votre tête pour planifier les posts ;-P.

Si tout se passe bien, vous verrez qu’il remarque qu’il y a un cron dans les logs :

[...]
2024-01-25T14:05:21+01:00 Importing cronjobs
2024-01-25T14:05:21+01:00 Starting crons setup
[...]
2024-01-25T14:06:05+01:00 (CRON) INFO (running with inotify support)
2024-01-25T14:06:05+01:00 (CRON) INFO (RANDOM_DELAY will be scaled with factor 89% if used.)
2024-01-25T14:06:05+01:00 (CRON) STARTUP (1.7.0)
[...]

Tout dernier point que j’ai éludé jusqu’à présent, il est possible de redémarrer une application à partir d’un cache (pour que ça aille plus vite). Cependant, il est nécessaire d’indiquer à clever cloud quoi mettre dans ce cache. On va donc ajouter “/clevercloud/cron.json:/clever_rebuild.sh” à la variable existante :

# précédemment CC_OVERRIDE_BUILDCACHE "/public"
$ clever env set CC_OVERRIDE_BUILDCACHE "/public:/clevercloud/cron.json:/clever_rebuild.sh"

(Fail to) hack the template

Si Hugo a bien un flag pour permettre de “builder” les posts dont la date de sortie est postérieure à la date actuelle (buildFuture), mon thème “Stack” les affiche par défaut dans la liste des derniers posts ainsi que dans le flux RSS.

La solution la plus simple à ce problème est de laisser les paramètres par défaut, et d’attendre que la date de publication soit dépassée (idéalement juste avant le passage d’un cron) et le tour est joué.

Mais David a eu une autre approche qui m’a bien plu : ajouter une condition dans le template pour que le post ne soit pas visible dans la liste des posts, mais quand même publié.

Avantage : on peut consulter l’article à paraître, si on a le lien. Il se rajoute à la liste des articles de la homepage de lui-même lors du prochain rebuild, une fois la date dépassée.

Dans mon thème, la page d’accueil qui liste les posts est définie ici dans le code :

 {{ define "main" }}
 {{ $pages := where .Site.RegularPages "Type" "in" .Site.Params.mainSections }}
 {{ $notHidden := where .Site.RegularPages "Params.hidden" "!=" true }}
+ {{ $notFuture := where .Site.RegularPages ".Date" "le" now }}
+ {{ $filtered := ($pages | intersect $notHidden | intersect $notFuture) }}
- {{ $filtered := ($pages | intersect $notHidden) }}
 {{ $pag := .Paginate ($filtered) }}

 <section class="article-list">
 {{ range $index, $element := $pag.Pages }}
 {{ partial "article-list/default" . }}
 {{ end }}
 </section>

 {{- partial "pagination.html" . -}}
 {{- partial "footer/footer" . -}}
 {{ end }}
[...]

En théorie, ça fonctionne. Sauf que je n’ai pas réussi à le faire marcher avec le thème “Stack” que j’utilise sur le site (j’ai réussi avec un thème “blank”).

C’est peut-être lié à un problème d’appel multiple à la fonction .Paginate(), qui “cache” la pagination la première fois qu’elle est lancée.

If you call .Paginator or .Paginate multiple times on the same page, you should ensure all the calls are identical. Once either .Paginator or .Paginate is called while generating a page, its result is cached, and any subsequent similar call will reuse the cached result. This means that any such calls which do not match the first one will not behave as written.

https://gohugo.io/templates/pagination/

Même en partant du principe que j’arrive à le faire marcher, reste encore la problématique du flux RSS, comme j’ai pu le remarquer avec Seboss666 ;-)

J’ai donc laissé tomber cette idée. De toute façon, je n’avais jamais vraiment eu besoin jusqu’à présent puisque je n’y avais pas pensé ;-P.

J’ai donc, comme avant, mes posts “planifiés” qui sont visible le matin de leur publication et c’est déjà bien comme ça (pour l’instant).

Have fun !

Migration du blog sur Clever Cloud

Sat, 30 Dec 2023 16:00:00 +0200

It’s groundhog migration day, again

Tous les 6 mois environ, une mouche me pique.

Après avoir migré un nombre incalculable de fois mon blog wordpress à droite / à gauche, puis migré sur Hugo, autohébergé, utilisé du managé chez vercel, chez froggit, autohébergé encore…

J’ai décidé (un peu sur un coup de tête) de migrer le blog chez les copain⋅es de chez Clever Cloud.

Et je vous montre comment j’ai fait.

Prérequis

Je pars du principe que vous avez comme moi un dépôt git / site hugo déjà fonctionnel. Et je ne vais pas non plus détailler la procédure pour activer un compte chez Clever Cloud.

Je commence par installer la CLI, les “clever tools”. Pour les installer, il nous faut npm. J’utilise rarement npm, mais quand je le fais, j’utilise un autre tool, volta (volta.sh), qui va me permettre de choisir la version dont j’ai besoin

$ curl https://get.volta.sh | bash

Une fois installé, je peux télécharger la version qui m’intéresse de npm (18 par exemple, la version minimum pour installer les clever tools)

$ volta install node@20
success: installed and set node@20.10.0 (with npm@10.2.3) as default

Je peux donc maintenant installer les clever tools :

npm i -g clever-tools

Puis me loguer depuis mon terminal

$ clever login
Opening https://console.clever-cloud.com/cli-oauth?cli_version=3.0.2&cli_token=xxxxxxxxxxxxxxxxx in your browser to log you in…
Login successful as [unspecified name] <xxx.yyy@example.org>

Si jamais comme indiqué sur l’écran de login, vous avez besoin d’un token + secret (pour de la CI par exemple), sachez qu’ils sont stockés dans un fichier ~/.config/clever-cloud/clever-tools.json

Denier prérequis, je vais ajouter une clé SSH dans ma console clever

Création de l’application

A partir de maintenant, je suis capable d’interagir avec clever cloud en CLI. Je vais commencer par créer l’application qui va héberger mon site statique :

$ clever create -t static-apache blog-zwindler
Your application has been successfully created!

Clever Cloud offre la possibilité de dissocier la taille des instances pour la partie run et la partie build. Je vais donc créer l’instance la plus petite possible pour le run (une nano), et une plus pêchue (une M) pour le build, histoire d’être plus réactif sur les commits de modifications :

$ clever scale --build-flavor M
App rescaled successfully
$ clever scale --flavor nano
App rescaled successfully

Je peux ensuite configurer quelques variables d’environnement (trouvées sur la doc de clever cloud) pour générer mon site statique avec l’image static-apache de clever.

$ clever env set CC_WEBROOT "/public"
$ clever env set CC_OVERRIDE_BUILDCACHE "/public"
$ clever env set CC_PRE_BUILD_HOOK "bash setup_hugo.sh"
$ clever env set CC_POST_BUILD_HOOK "hugo --minify --gc"

Pour finir, on crée le script setup_hugo.sh à la racine de notre site statique Hugo :

cat > setup_hugo.sh << EOF
HUGO_VERSION="0.121.1"
HUGO_URL="https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz"
DEST_BIN="${HOME}/.local/bin"
FILENAME="hugo.tar.gz"

# Download Hugo Extended and place it in a folder in the $PATH
curl --create-dirs -s -L -o ${DEST_BIN}/${FILENAME} ${HUGO_URL}
cd ${DEST_BIN}
tar xvf ${FILENAME} -C ${DEST_BIN}
rm ${FILENAME}
EOF

On commit les fichiers créés :

git add .
git commit -m "Add clever"

Déployer notre code

A partir de là, on a notre instance qui est prête à démarrer, dès qu’elle aura reçu du code.

Ici, clever cloud attend un push sur un dépôt git.

La méthode la plus “simple” pour pousser du code sur clever à ce moment-là est donc de créer un dépôt distance (remote) :

git remote add clever git+ssh://git@push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git
git push clever master

Le “problème” dans mon cas est que (pour l’instant), le nom de la branche n’est pas configurable et est forcément “master”, ce qui ne m’arrange pas puisque je bosse habituellement sur “main”.

remote: Error: You tried to push to a custom branch. This is not allowed.
remote: error: hook declined to update refs/heads/main
To git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git
! [remote rejected] main -> main (hook declined)
error: impossible de pousser des références vers 'git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git'

2 manières de contourner ce problème :

soit je force la branche master sur le remote clever dans git
soit j’utilise la CLI clever deploy

Dans un premier temps, je me contente de feinter git :

git push clever main:master
Énumération des objets: 30, fait.
Décompte des objets: 100% (24/24), fait.
Compression par delta en utilisant jusqu'à 16 fils d'exécution
Compression des objets: 100% (16/16), fait.
Écriture des objets: 100% (16/16), 287.70 Kio | 31.97 Mio/s, fait.
Total 16 (delta 8), réutilisés 0 (delta 0), réutilisés du pack 0
remote: [SUCCESS] The application has successfully been queued for redeploy.
To git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git
54ff42f..960ce62 main -> master

On termine par la configuration du nom de domaine :

$ clever domain add blog.zwindler.fr
Your domain has been successfully saved

Il ne nous reste plus qu’à mettre à jour le CNAME dans notre DNS (domain.par.clever-cloud.com. dans mon cas, mais la bonne configuration est visible dans l’onglet Domain names de l’application)

Et avec `clever deploy` ?

Eh bien en fait, c’est “encore plus simple”. Il me suffit juste de faire une modif, de commit

git add .
git commit -m "test clever deploy"

Puis de simplement lancer la commande clever deploy.

$ clever deploy
Remote git head commit is c4e3c283585cafff44f07c7d78d860065318cd68
Current deployed commit is c4e3c283585cafff44f07c7d78d860065318cd68
New local commit to push is 0b3536a9f1d61178a99f6238831ccb4197989ddf (from refs/heads/main)
Pushing source code to Clever Cloud…
Your source code has been pushed to Clever Cloud.
Waiting for deployment to start…
Deployment started (deployment_b5f841ff-a233-4bb4-8a16-f618ee69ef28)
Waiting for application logs…
[...]

Quelle est donc cette diablerie ?

En réalité, les informations nécessaires pour pousser le code sont en réalité simplement dans un fichier .clever.json qui a été créé à la racine lorsqu’on a lancé la commande clever create -t static-apache blog-zwindler au tout début du tuto.

{
 "apps": [
 {
 "app_id": "app_xxxxxxxxxxxxxxxxxxx",
 "org_id": "user_yyyyyyyyyyyyyyyyyyyyy",
 "deploy_url": "https://push-n3-par-clevercloud-customers.services.clever-cloud.com/xxxxxxxxxxxxxxxxxxxx.git",
 "name": "blog-zwindler",
 "alias": "blog-zwindler"
 }
 ]
}

Évidemment, je ne vais pas m’amuser à faire un clever login / clever deploy à chaque fois que je veux pousser une modif sur mon blog. Et c’est là où nos CLEVER_TOKEN / CLEVER_SECRET seront utiles !

Conclusion

Après quelques heures d’usage, je peux dire que dans le cadre de l’hébergement de mon blog, j’aime bien utiliser Clever Cloud.

Qu’on soit bien clair, c’est pour mon cas d’usage et comparé à :

Vercel : l’expérience utilisateur est incroyable sur Vercel, mais j’ai toujours été un peu gêné par le côté “boite noire” (on a pas accès à beaucoup plus que des variables d’environnement). Et je ne parle pas des problématiques de privacy…
Deux serveurs physiques avec Proxmox VE en cluster étendu chez One-provider : à l’inverse héberger moi-même mon blog sur une machine (en vrai, 2) louée résout les problèmes de privacy et j’ai la main sur toute la stack, mais ça me demande de la maintenance pour des perfs minables. Ok, c’est pas cher, mais j’ai 2 à 3 minutes de rebuild avec le CPU à 100% sur mon Atom de 2010 chez Online…
Froggit : c’était du Gitlab + Gitlab pages et c’était très cool car c’est plus flexible que Vercel, mais j’avais dû passer un peu de temps à configurer la pipeline et leur faire pousser les murs pour que mon site rentre (les 400 Mo de médias n’étaient pas supportés au début et les transferts Gitlab => Gitlab pages étaient un peu longs).

Avec Clever, mes 450 articles (3600 pages générées, 400 Mo de média) sont très rapidement générés, transférés, et enfin mis à disposition (< 1 minute tout compris, plus rapide que les 3 solutions précédentes).

Le tout avec une disponibilité/fiabilité sans aucun doute bien meilleure que ce que j’aurais pu faire moi-même en auto hébergé avec un coût similaire, et en très peu de temps.

J’ai passé beaucoup plus de temps à écrire cet article qu’à migrer le blog, puisque la doc est bien écrite, le site est intuitif, et je n’ai été bloqué à aucun moment.

Il me reste encore à optimiser l’étape de déploiement, pour qu’un commit/push sur mon dépôt git déclenche automatiquement un déploiement côté clever. Objectivement, ça ne devrait pas prendre trop longtemps (github action / gitlab CI)…

Et par contre, ça manque d’IPv6 natif, screugneugneu !

Automatiser son site Hugo sans Github Action ou Vercel

Tue, 01 Aug 2023 06:00:00 +0200

Contexte

Fin 2021, après plus de 10 ans à écrire des articles de blog tech sur Wordpress, je prenais la décision radicale d’arrêter de maintenir cette bouse infâme (je mâche mes mots) et de partir sur des articles rédigés en markdown et un site statique avec Hugo.

Au tout début, je gérais le blog moi-même mais assez vite j’en ai eu assez de devoir aller rebuild le blog à chaque modification. J’ai rapidement mis un cron qui faisait des git pull régulièrement, mais on ne va pas se mentir, c’est assez crado…

Finalement, on m’a rapidement pointé que je devrais arrêter de m’embêter et utiliser Netlify ou Vercel.

J’étais pas super chaud, car ça allait à l’encontre de ma volonté d’auto héberger mon contenu et de limiter l’impact sur la vie privée de mes lecteurs, mais finalement, l’expérience utilisateur sur Vercel était tellement bonne que j’avais craqué. Je ferai peut-être un article là-dessus d’ailleurs, c’est la première fois que j’ai compris (ressenti) l’intérêt d’un PaaS.

Mais aujourd’hui, je reviens sur cette décision et j’essaye de voir ce qu’il est nécessaire de mettre en place pour disposer soi-même d’un site hugo qui se refresh tout seul dès qu’un commit arrive sur le dépôt git, sans utiliser de plateforme type Vercel ni d’outils types Github action+pages.

Prérequis

Je pars du principe que vous avez déjà un site statique généré avec Hugo. Si ce n’est pas le cas je vous invite à aller lire mes articles précédents sur le sujet (premiers pas, stats avec matomo, migration wordpress vers hugo).

Vous avez donc un serveur Linux sur lequel vous avez la main pour installer des choses et un dépôt git (sous Github dans mon cas, mais on peut probablement adapter l’article pour autre chose).

Hugo étant d’abord un générateur de site statique, je vais utiliser nginx en frontal pour servir les fichiers qu’on va générer. Jusqu’à il y a peu, l’usage du mode “server” de hugo n’était d’ailleurs pas conseillé en production (mais ça ne semble plus être le cas, je n’ai pas vu de warning dernièrement ?).

apt install nginx git

Déposer les sources sur le serveur

Dans mon cas, les sources de mon blog ne sont pas disponibles publiquement (parce que j’ai pas envie, c’est comme ça ¯\_(ツ)_/¯).

Il faut donc préalablement se loguer en SSH avec git avant de pouvoir pull le code. Et comme je n’ai pas envie de laisser ma clé privée sur le serveur qui va héberger mon blog, il faut que j’utilise une autre clé.

Dans mon cas, Github, qui héberge le code markdown de mon blog, a une notion de “deploy keys”, qui servent justement pour ça :

docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys

Je vais donc créer une clé sur le serveur qui héberge le blog :

ssh-keygen -t ed25519 -C "xxx@xxx.tld"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/toto/.ssh/id_ed25519):
[...]

Et je la copie dans le dossier de www-data (l’utilisateur nginx sous Ubuntu)

chmod 600 /root/.ssh/id_ed25519
sudo mkdir /var/www/.ssh/
sudo cp ~/.ssh/id_ed25519* /var/www/.ssh/
chown www-data: /var/www/.ssh/*

Une fois la clé créée, on doit l’ajouter dans Github.com. Je ne lui donne que les droits “read only” puisque le but c’est seulement de récupérer le code et générer le site statique, pas qu’on puisse éditer le code (cé pour la sécuritay).

Je retourne ensuite sur mon serveur et j’essaye de télécharger les sources et le thème:

cd /usr/share/nginx/html
GIT_SSH_COMMAND='ssh -i /var/www/.ssh/id_ed25519 -o IdentitiesOnly=yes' git clone git@github.com:zwindler/blog.example.org.git
cd blog.example.org/themes
git submodule add -f https://github.com/CaiJimmy/hugo-theme-stack.git
chown -R www-data: /usr/share/nginx/html/blog.example.org

Webhook

Pour réagir à l’arrivée d’un nouveau commit sur notre dépôt source, on va utiliser 2 choses :

un projet qui s’appelle sobrement “Webhook”.
configurer un webhook dans github, qui va envoyer l’info que quelque chose est arrivé sur le dépôt (mais on verra ça plus tard)

Revenons à “Webhook” dans un premier temps :

webhook is a lightweight configurable tool written in Go, that allows you to easily create HTTP endpoints (hooks) on your server, which you can use to execute configured commands. You can also pass data from the HTTP request (such as headers, payload or query variables) to your commands. webhook also allows you to specify rules which have to be satisfied in order for the hook to be triggered.

On récupère la dernière release et déposer le binaire sur notre serveur :

github.com/adnanh/webhook/releases/tag/2.8.1

export VERSION="2.8.1"
wget https://github.com/adnanh/webhook/releases/download/${VERSION}/webhook-linux-amd64.tar.gz

tar -xvf webhook*.tar.gz

sudo mv webhook-linux-amd64/webhook /usr/local/bin
rm -rf webhook-linux-amd64*

webhook --version

Une fois que c’est fait, on va générer une chaîne aléatoire qui va nous servir de “secret” qui sera partagé entre le binaire webhook qui tourne sur notre serveur et un webhook sur Github.com :

WHSECRET=`uuidgen | base64`
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa==

On crée un fichier de configuration hook.json pour déclarer nos webhooks

mkdir /etc/webhook
cat > /etc/webhook/hook.json << EOF
[
 {
 "id": "redeploy",
 "execute-command": "/usr/share/nginx/html/blog.example.org/blog_refresh.sh",
 "command-working-directory": "/usr/share/nginx/html/blog.example.org",
 "trigger-rule":
 {
 "match":
 {
 "type": "payload-hmac-sha1",
 "secret": "$WHSECRET",
 "parameter":
 {
 "source": "header",
 "name": "X-Hub-Signature"
 }
 }
 }
 }
]
EOF

Ici, quand le serveur va recevoir l’url /hooks/redeploy, on va lancer le script /usr/share/nginx/html/blog.example.org/blog_refresh.sh depuis le répertoire /usr/share/nginx/html/blog.example.org.

Charge à nous de créer un script qui va soit :

récupérer les sources (git pull)
relancer un build

Voilà à quoi pourrait ressembler le script blog_refresh.sh :

#!/bin/bash
cd /usr/share/nginx/html/blog.example.org

#pull latest version
GIT_SSH_COMMAND='ssh -i /var/www/.ssh/id_ed25519 -o IdentitiesOnly=yes' git clone git@github.com:zwindler/blog.example.org.git

#refresh theme submodule
git submodule init
git submodule update

#rebuild (fire and forget)
hugo --minify --gc &

On va ensuite créer un service systemd qui va lancer le binaire webhook en tâche de fond

cat > /etc/systemd/system/webhook.service << EOF
[Unit]
Description=Simple Golang webhook server
ConditionPathExists=/usr/local/bin/webhook
After=network.target

[Service]
User=www-data
Group=www-data
Type=simple
WorkingDirectory=/usr/share/nginx/html/blog.example.org
ExecStart=/usr/local/bin/webhook -ip 127.0.0.1 -hooks /etc/webhook/hook.json -verbose
Restart=on-failure

[Install]
WantedBy=default.target
EOF

systemctl enable webhook
systemctl start webhook

Côté Github.com, on crée le webhook qui va contacter le serveur webhook de la façon suivante :

On a maintenant un serveur web qui est en attente de certains événements webhooks et qui va lancer un script si jamais l’URL de webhook est appelée par Github.com.

Configuration nginx

Il reste maintenant toute la configuration de notre nginx en frontal à faire. En partant du principe qu’on vient juste de faire l’installation du package, on commence par supprimer le fichier /etc/nginx/sites-enabled/default, et on en crée un nouveau :

rm /etc/nginx/sites-enabled/default

cat > /etc/nginx/sites-available/blog.example.org.conf << EOF
# Root configuration
server {
 listen 80;
 server_name blog.example.org;

 location /hooks/ {
 proxy_pass http://127.0.0.1:9000/hooks/;
 }

 error_page 404 /404.html;

 location / {
 root /usr/share/nginx/html/blog.example.org/public;
 index index.html;
 }
}
EOF
ln -s /etc/nginx/sites-{available,enabled}/blog.example.org.conf

On vérifie que la configuration est valide et si oui on redémarre nginx

nginx -t
systemctl reload nginx

A partir de maintenant, toutes les URLs qui arriveront jusqu’à votre serveur en /hooks seront redirigées sur le logiciel “webhook” et le reste ira sur votre site statique (/usr/share/nginx/html/blog.example.org/public).

curl https://blog.example.org/hooks/redeploy -L
Hook rules were not satisfied.%

Ici le hook renvoie une erreur, car on a pas envoyé le token secret mais c’est probable que ça fonctionne. Toutes les autres pages renvoient bien une page du blog :

curl https://blog.example.org/
<!DOCTYPE html>
<html lang="fr-fr" dir="ltr">
 <head>
 <meta name="generator" content="Hugo 0.115.1"><meta charset='utf-8'>
[...]

On peut maintenant envoyer des commits et voir si ça déclenche des rebuilds de notre blog. Ou alors, on peut récupérer un push précédent et cliquer sur “Redeliver” si on veut trigger un rebuild du blog.

root@hugo:~# systemctl status webhook
* webhook.service - Simple Golang webhook server
 Loaded: loaded (/etc/systemd/system/webhook.service; enabled; vendor preset: enabled)
 Active: active (running) since Mon 2023-07-31 07:34:35 UTC; 33s ago
 Main PID: 900109 (webhook)
 Tasks: 15 (limit: 4574)
 Memory: 240.4M
 CPU: 45.504s
 CGroup: /system.slice/webhook.service
 |-900109 /usr/local/bin/webhook -ip 127.0.0.1 -hooks /etc/webhook/hook.json -verbose
 `-900161 hugo --minify --gc

Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 attempting to load hooks from /etc/webhook/hook.json
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 found 1 hook(s) in file
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 loaded: redeploy
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 serving hooks on http://127.0.0.1:9000/hooks/{id}
Jul 31 07:34:35 hugo webhook[900109]: [webhook] 2023/07/31 07:34:35 os signal watcher ready
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] incoming HTTP POST request from 127.0.0.1:43258
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] redeploy got matched
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] redeploy hook triggered successfully
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] 200 | 0 B | 1.151688ms | 127.0.0.1:9000 | POST /hooks/redeploy
Jul 31 07:34:41 hugo webhook[900109]: [webhook] 2023/07/31 07:34:41 [f089a0] executing /usr/share/nginx/html/blog.example.org/blog_refresh.sh
[...]
Jul 31 07:37:28 hugo webhook[900109]: Pages | 3572
Jul 31 07:37:28 hugo webhook[900109]: Paginator pages | 516
Jul 31 07:37:28 hugo webhook[900109]: Non-page files | 14
Jul 31 07:37:28 hugo webhook[900109]: Static files | 2282
Jul 31 07:37:28 hugo webhook[900109]: Processed images | 2
Jul 31 07:37:28 hugo webhook[900109]: Aliases | 1563
Jul 31 07:37:28 hugo webhook[900109]: Sitemaps | 1
Jul 31 07:37:28 hugo webhook[900109]: Cleaned | 0
Jul 31 07:37:28 hugo webhook[900109]: Total in 166131 ms
Jul 31 07:37:28 hugo webhook[900109]: [webhook] 2023/07/31 07:37:28 [f089a0] finished handling redeploy

Conclusion

Si vous êtes à l’aise avec Linux et nginx, ces quelques manipulations sont assez rapides à faire, il n’y a rien de vraiment complexe.

Cependant, ça demande à l’usage un peu d’administration et de vouloir mettre les mains dans le cambouis (avoir une VM à gérer). Je ne peux reprocher à personne de préférer l’utilisation de Github/Gitlab pages, couplé à de Github actions/Gitlab runners, voire de tout déléguer à Vercel/Netlify…

Mais j’avais envie de reprendre la main sur le hosting de mon blog (avec tous les inconvénients que ça va avoir en termes de maintien en condition opérationnelle), notamment pour disposer à nouveau de l’IPv6 (perdue lors du passage à Vercel) et une navigation sur mon blog plus respectueuse de votre vie privée (pas que j’aie pas confiance en Vercel, mais bon…).

Et c’est en revanche beaucoup plus simple que d’héberger son propre serveur Gitlab + Gitlab runners + Gitlab pages ;-).

Donc, pour mon usage, ça fait le taf :)

Hugo on Zwindler's Reflection

Refonte de la page Conférences : data-driven avec Hugo

Le problème

L’approche : données + layouts + CSS

Les données YAML

data/conferences.yaml

Les pages Markdown minimalistes

Le layout Hugo

Le CSS : des cartes partout

Bilan

De F à A+ sur HTTP Observatory : sécuriser les headers de mon blog Hugo

Le déclic

Ce que teste HTTP Observatory

Étape 1 : les headers “faciles”

Étape 2 : Content-Security-Policy (la vraie difficulté)

Inventaire des ressources externes

Le problème des scripts d’analytics externes

Supprimer unsafe-inline de script-src

Supprimer unsafe-inline de style-src, la suite

La CSP finale

Nettoyage bonus : Mailchimp

Résultat final

J'ai donné 1 heure à des agents Copilot pour migrer un site de Bloggrify à Hugo

TL;DR pour les pressés

Le contexte : pourquoi se faire mal ?

Phase 1 : La migration technique (15 minutes)

Phase 2 : La page “À propos” (20-25 min, et des “““hallucinations”””)

Phase 3 : Les tâches techniques (et là, ça roule)

Comportement bizarre : PR ou commit direct ?

Un PaaS, ça aide

Conclusion

Ce blog est (enfin) multilingue

Une évolution qui s’imposait

URLs conservées

L’implémentation technique

Des traductions à venir (peut-être ?)

Références

Je réessaye les sites statiques (Bloggrify) chez Clever Cloud

Introduction

Prérequis

Configuration de l’app

Déploiement de l’application

Ajouter un domaine

Automatiser le clever deploy

deploy-to-clever-cloud

preview par PR

Créer des tokens de CI

Déploiements depuis GitHub (ou GitLab)

Conclusion

Planifier les posts de mon blog Hugo sur Clever Cloud

Suite de la migration

Adaptations

(Fail to) hack the template

Migration du blog sur Clever Cloud

It’s groundhog migration day, again

Prérequis

Création de l’application

Déployer notre code

Et avec clever deploy ?

Conclusion

Automatiser son site Hugo sans Github Action ou Vercel

Contexte

Prérequis

Déposer les sources sur le serveur

Webhook

Configuration nginx

Conclusion

Ressources additionnelles

`data/conferences.yaml`

Supprimer `unsafe-inline` de `script-src`

Supprimer `unsafe-inline` de `style-src`, la suite

Automatiser le `clever deploy`

Et avec `clever deploy` ?