Capture de la page d'accueil de bencat.dev en thème sombre : à gauche l'article à la une, Le Seigneur des Workflows, et son illustration ; à droite la revue du jour et les derniers articles.
← tous les projets

bencat.dev

Le site que vous êtes en train de consulter : blog, projets, prompts et skills, en Astro, éditable depuis un CMS git sans backend.

// aperçu

Ce site remplace mon ancien blog Hugo. Même foutoir, autre socle : Astro en statique, Tailwind v4 pour le thème, TypeScript pour la logique du site, et Sveltia CMS pour écrire sans toucher au code.

Cette page s’adresse à ceux que la plomberie intéresse. Si vous êtes venus pour le contenu, le blog est par là, j’le vivrai bien.

Ce qu’il y a sous le capot

Le contenu vit en page bundles : un dossier par article, avec ses images à côté, validés par des schémas Zod. Le CMS est une page statique servie sur /admin : le navigateur parle directement à l’API GitHub avec un jeton personnel, donc aucun backend à héberger. Par défaut, un enregistrement reste sur une branche cms/…, et la publication fusionne sur main. Pour une correction immédiate, « Enregistrer et publier » va droit sur main. Dans les deux cas, ça déclenche le déploiement sur mon Raspberry Pi.

Schéma du trajet d'une publication, de haut en bas. Dans mon navigateur, Sveltia CMS sur /admin fait par défaut un commit par l'API GitHub sur une branche cms/…, et la publication fusionne cette branche sur main. En pointillé, « Enregistrer et publier » va droit sur main. Dans les deux cas, le push sur main lance GitHub Actions, qui teste puis construit la version prod et la version preview. Les artefacts arrivent sur le Raspberry Pi : le runner pi-site les copie sous /srv/site et bascule le lien current. Caddy sert ce lien, et le visiteur de bencat.dev reçoit le site en HTTPS.

Un runner auto-hébergé, ça mérite un peu de parano. Le mien tourne avec un utilisateur sans sudo ni docker, et le workflow n’a aucun déclencheur pull_request : il n’exécute que du code déjà sur main, ou lancé à la main par moi. Son boulot se résume à copier des fichiers sous /srv/site, que Caddy sert en lecture seule.

git push, et après ? Qui m’arrête quand je me plante

Tout passe par un seul fichier, deploy.yml, à lire dans l’onglet Code. Voilà ce qui peut y bloquer une mise en ligne :

ÉtapeOù ça tourneCe qui peut tout arrêter
TestsGitHub Actionsnpm test, puis npm run check
BuildGitHub Actions, une fois par versionnpm run build, ou un artefact vide
PublicationRunner du Raspberry PiUn artefact sans index.html
Contrôle finalRunner du Raspberry PiUn accueil servi par Caddy qui diffère de celui publié, ou des brouillons sans mot de passe

Le contenu a droit à son contrôle technique, lui aussi. Le CMS réécrit mes fichiers à sa façon, alors avant chaque commit, je vérifie que tout est déjà dans la forme qu’il écrirait :

bencat.dev
$ TZ=Europe/Paris node scripts/canonicalize-content.mjs --check
canonical: 15/15 entries
$ echo $?
0

404 Not Found : la purge qui marchait trop bien

Le Pi garde cinq versions par site, la prod et la preview, et purge les autres. Sur le papier, c’est propre. Dans les faits :

Le correctif tient en deux gestes : incoming/ est vidé avant le téléchargement, sinon les fichiers retirés du site seraient republiés, et la version publiée récupère sa date.

# cp -a recopie la date de $src : sans touch, la purge ci-dessous
# peut trier la nouvelle version en dernier et la supprimer.
touch "$root/$release"

Où j’en suis

Tout est en ligne : le blog, le CMS, la vitrine projets, les bibliothèques de prompts et de skills, et la recherche.

Le site est construit plan par plan, avec une méthode anti-dérive : une spec à critères binaires par plan, un journal de périmètre tenu à jour à chaque tâche, et un audit de vérification obligatoire avant de livrer un plan. Ça fait beaucoup de paperasse pour un site perso, je sais. Mais le premier commit du dépôt, c’est cette méthode et le design, et la méthode dit pourquoi mieux que moi :

Sans cadre, ce type de build multi-sessions perd du périmètre en silence : une page à moitié faite, une collection oubliée, un critère validé « à peu près ».

— la méthode du site, 19 juillet 2026

GitHub Actions, c’est aussi mon terrain de jeu ailleurs, avec cette petite action pour les numéros de version :

Projetgha-svu — le versionnage sémantique dans GitHub ActionsUne action composite qui calcule la prochaine version sémantique avec SVU v3, et pose le tag si tu lui demandes.

EXIT 0

Si vous lisez ces lignes, c’est que la purge s’est tenue tranquille. Merci d’être passés !

// stack

// code

// journal

// articles liés

Tapez au moins 2 caractères.

télécharger ↓