DOXMOX - monitoring les changements du guide Proxmox VE avec GitHub Actions

Hello, World!

J’ai remarqué un pattern simple: avant une mise à jour, ou avant une release qui impacte le fonctionnement de Proxmox VE, la documentation est aussi mise à jour. C’est logique.

Je voulais suivre les changements du guide Proxmox VE. Le besoin est simple: être prévenu quand le contenu change vraiment, garder une trace lisible des différences, et pouvoir relire l’historique plus tard.

Ce bot sert à voir ces changements de documentation dès qu’ils apparaissent.

J’ai construit DOXMOX pour ce cas. (Lien du projet: doxmox.com ) Le projet tourne sur GitHub Actions toutes les X heures, compare la version courante avec la précédente, puis publie un changelog statique.

DOXMOX ne prédit pas les releases Proxmox VE. Il détecte les modifications de documentation et donne un signal exploitable pour vérifier ce qui change avant les mises à jour.

---

Le pipeline réel

Le script télécharge la page source avec requests et gère les erreurs réseau classiques (429, 5xx) avec des tentatives de reprise. Le HTML est ensuite normalisé: sélection des zones utiles (header, toc, content, footer) et suppression de bruit (script, noscript).

Sur ce contenu normalisé, doxmox calcule un SHA-256. Si le hash n’a pas changé, le run s’arrête. Si le hash change, le script génère un diff texte (docs/changes/<timestamp>.diff), sa version HTML, une nouvelle entrée dans data/history.json, puis met à jour docs/index.html.

Le workflow commit et push les artefacts, puis envoie l’alerte Telegram. Le bootstrap initial n’envoie pas d’alerte pour éviter le bruit.

---

Pourquoi ce design tient en production

Comparer du HTML brut crée beaucoup de faux positifs. Un changement de bannière, d’ordre d’attributs, ou de bloc JS casse le hash sans impact sur la doc. La normalisation retire ce bruit. Le hash reflète donc le texte utile.

L’archive des diffs me fait gagner du temps. Quand une alerte arrive, je n’ai pas besoin de relire toute la page source. J’ouvre docs/index.html, je clique sur l’entrée, et je vois immédiatement la différence entre deux versions.

Pour la maintenance, j’ai gardé deux chemins pour nettoyer l’historique: par le workflow admin pour une action depuis GitHub, ou en CLI quand je veux agir localement.

---

Ce que j’utilise au quotidien

Le projet est en production sur GitHub Actions + GitHub Pages. Dans la pratique, il me sert pour trois actions concrètes.

• Je vérifie rapidement si le changement touche des procédures critiques (installation, réseau, stockage).
• Je garde un historique daté de ce qui a changé, utile quand je dois expliquer pourquoi une procédure interne a été modifiée.
• Je réduis le temps passé en veille manuelle: je lis les diffs uniquement quand il y a un vrai changement.

Quand la doc ne change pas, DOXMOX ne notifie pas. Le but est de réduire le bruit, pas de générer un flux d’alertes permanent.

---

Limites connues

Le projet dépend de la structure HTML de la page source. Si cette structure change fortement, la normalisation doit être adaptée. Le diff est textuel. Il ne comprend pas la sémantique du contenu. Le périmètre est volontairement simple: une source, un historique, un site statique.

Lien du projet: doxmox.com

Thanks!