Chaîne de publication

Les pages sont modifiées sous forme de fichiers Org Mode dans content/, normalement depuis Emacs.

La source reste du texte ordinaire adapté aux diffs Git, à la revue, à la recherche et à l'archivage à long terme.

Pendant l'édition :

make serve

qui effectue un build de production complet puis lance :

python3 -m http.server --directory public 1313

Cela prévisualise exactement les fichiers générés. Le site peut ensuite être inspecté à l'adresse :

http://localhost:1313/

Le serveur de développement n'est qu'un outil de prévisualisation locale. Il ne fait pas partie de l'architecture de production.

Un build de production est généré avec :

make build

Le Makefile exécute Hugo puis construit l'index de recherche SQLite FTS5 du site.

Le site généré et la base de recherche sont écrits dans public/. Aucun JavaScript n'est nécessaire ni livré dans les pages générées.

Avant déploiement :

make check

Cette commande réalise un build de production propre puis valide le site généré. Les contrôles automatisés couvrent actuellement :

• la syntaxe Python des utilitaires de build et CGI ;
• la présence de index.html, robots.txt, sitemap.xml et search.db ;
• les liens internes cassés et ressources locales manquantes ;
• la présence de JavaScript dans le HTML généré ;
• les feuilles de style externes inattendues.

Les contrôles opèrent sur l'arborescence public/ générée, c'est-à-dire les mêmes fichiers que servira nginx. Une inspection manuelle reste utile pour le rendu, la mise en page responsive, l'ordre de navigation et l'apparence claire/sombre.

Le déploiement est effectué avec rsync via le Makefile :

make deploy

La cible deploy dépend de check. Un échec de build ou de validation arrête donc le déploiement avant l'appel à rsync.

Le Makefile fournit des valeurs par défaut pour la destination SSH et le répertoire de production :

REMOTE ?= fgm@m710s
REMOTE_DIR ?= /srv/www/html

Les deux variables sont volontairement surchargeables, par exemple :

make deploy REMOTE=server REMOTE_DIR=/srv/www/site

Le déploiement exclut l'arborescence OpenPGP WKD afin que la publication du site ne supprime pas les fichiers WKD gérés indépendamment.

L'historique des sources est conservé dans Git. Une révision antérieure peut donc être reconstruite et redéployée si nécessaire.

Pour un petit site statique, cette approche est préférable au maintien d'un contenu mutable dans une application ou une base de données de production.

Les versions récentes de Hugo refusent par défaut le contenu Org parce que certaines constructions d'export Org peuvent émettre du HTML brut ou du JavaScript.

Ce dépôt autorise explicitement text/org dans hugo.toml parce que les sources Org sont rédigées et revues localement. Du contenu provenant de contributeurs non fiables ne devrait pas être accepté dans cette chaîne sans revue.