Merge remote-tracking branch 'origin/doc-derniers-articles'

docs/technique/deploiement-wiki.md

@@ -181,6 +181,49 @@ Une exécution réussie encadre le build par une ligne `Deploy started` et une l
 
 ---
 
+## Ce que le build publie pour la page d'accueil
+
+Chaque build écrit, à la racine du site, un fichier **`derniers-articles.json`** : les
+vingt dernières pages créées ou modifiées, avec leur titre, leur adresse et la date du
+commit qui a touché leur contenu. C'est ce fichier que lit la page d'accueil
+d'alpinux.org pour afficher « Le wiki, fraîchement mis à jour ».
+
+Il est produit par le hook `hooks/derniers_articles.py`, déclaré dans `mkdocs.yml`.
+Trois choses à savoir :
+
+- **Un déplacement n'est pas une mise à jour.** Les dates viennent de `git log` avec
+  suivi des renommages : déplacer `guides/truc.md` ne fait pas remonter l'article en
+  tête de liste, seule une modification de son texte le fait.
+- **Seules les pages de la navigation sont annoncées.** Une page absente de `nav` —
+  typiquement la redirection laissée derrière un article déplacé — n'apparaît jamais
+  dans la liste.
+- **Le hook n'échoue jamais.** Sans historique git, il n'écrit rien et le build
+  continue ; l'accueil d'alpinux.org masque alors simplement sa section wiki. Ses
+  messages sont pour cela de niveau *info* et jamais *warning* : le déploiement
+  construit avec `--strict`, où un seul avertissement suffit à interrompre le build,
+  et donc la publication.
+
+Le même hook pose l'en-tête `Access-Control-Allow-Origin` sur ce seul fichier, au
+moyen d'un `.htaccess` déposé à la racine du site construit. Sans lui, le navigateur
+refuserait à alpinux.org le droit de lire une réponse venue de wiki.alpinux.org.
+
+!!! warning "Deux conditions"
+    **Le clone doit avoir son historique.** Un clone `--depth 1` ne porte qu'un
+    commit : toutes les pages sembleraient modifiées le même jour. Le hook le détecte
+    et le signale dans le journal du build, sans rien casser.
+
+    **Un `.htaccess` posé à la main sur le serveur est effacé au déploiement suivant**,
+    puisque le staging est recopié avec `rsync --delete`. Pour ajouter des règles
+    Apache durables, placez-les dans `docs/.htaccess` : MkDocs le recopie dans le site
+    construit, et le hook **ajoute** son bloc à la suite au lieu de le remplacer.
+
+```bash
+# vérifier ce que le dernier build a publié
+curl -s https://wiki.alpinux.org/derniers-articles.json | head -20
+```
+
+---
+
 ## En cas d'erreur de build
 
 Si `mkdocs build` échoue, le site en ligne **n'est pas modifié** — l'ancien contenu reste en place. Lisez le message d'erreur : il indique généralement le fichier et la ligne problématiques.
@@ -212,4 +255,5 @@ Ouvrez [http://localhost:8000](http://localhost:8000) — MkDocs recharge automa
 | Vérifier le build avant de pousser | `mkdocs build --strict -d /tmp/wiki-build` |
 | Déployer à la main (webhook en panne) | `deploy-wiki.sh`, sur le serveur |
 | Voir le journal des déploiements | `tail -20 /var/log/wiki-deploy.log` |
+| Vérifier la liste envoyée à l'accueil | `curl -s https://wiki.alpinux.org/derniers-articles.json` |
 | Régénérer les fichiers du logo (poste local) | `python3 scripts/build-assets.py` |