[ohugonnot]

Refs #267

Ce que fait cette PR

Ajoute un workflow « Build du wiki » qui tourne sur chaque PR (et sur main, et à la main) :

1. Contrôle des liens et images (npm run test:links) : le rapport complet s'affiche. La CI bloque déjà la catégorie casse (liens dont seule la casse diffère, ex. jobs au lieu de Jobs) : elle est à zéro sur main, et ce sont justement les liens qui marchent sous Windows et cassent sur le serveur Linux. Les autres catégories seront bloquées au fur et à mesure qu'elles tombent à zéro (fix: liens à antislash et menu des métiers (#117) #350 pour les antislashs). Si le contrôle bloque, la liste des liens à corriger s'affiche dans le journal.
2. Build complet des 4 langues, avec la même version de Node (.nvmrc) et le même plafond mémoire que le Dockerfile : une PR qui casse le build se voit avant la fusion, sans charger le VPS.

Au passage :

• scripts/check_links.py --fail-on refuse maintenant une catégorie inconnue (une faute de frappe désactivait le contrôle sans prévenir).
• Supprime jekyll.yml : modèle GitHub jamais adapté ($default-branch jamais remplacé), il ne s'est jamais déclenché (0 exécution dans l'historique Actions), et le site n'est pas fait avec Jekyll.

Ce que cette PR ne fait pas (à décider)

L'issue #267 dit « pour pouvoir update plus facilement les articles ». Cette PR vérifie chaque PR mais ne déploie pas : le déploiement automatique touche au serveur (accès, secrets), c'est à voir avec @mortifia. D'où « Refs » et pas « Closes ».

Le test e2e des traductions sera ajouté à ce workflow par la PR de #268, qui apporte le script.

Comment c'est vérifié

• actionlint : aucune erreur
• en local : étape liens → code 0 avec le rapport ; faute de frappe dans --fail-on → code 2 ; lien casse dans un jeu de test → code 1 et le lien listé
• build avec le plafond mémoire du Dockerfile (1024 Mo) : OK
• l'exécution réelle de ce workflow sur cette PR (onglet Checks)

[ohugonnot]

@mortifia une proposition pour la 2e moitié de #267 (« pour pouvoir update plus facilement les articles »), à toi de voir puisque ça touche au serveur :

Constat : aujourd'hui le site se reconstruit à la main sur le VPS (docker compose build). #347 est fusionnée depuis ce matin mais pas encore en ligne, et #332 rappelle que le build sur le VPS (1 vCPU / 2 Go partagés) a déjà échoué faute de mémoire.

Proposition : que GitHub construise l'image, et que le VPS se contente de la récupérer.

1. Sur chaque fusion dans main, un workflow construit l'image Docker (le Dockerfile actuel, inchangé) et la publie sur le registre GitHub (ghcr.io/unitystation-fork/unitystation-wikiv2:latest). Il faut seulement permissions: packages: write dans le workflow, aucun secret à ajouter.
2. Côté VPS, docker-compose.yml passe de build: . à image: ghcr.io/…:latest, puis au choix :
   • Watchtower (un conteneur qui vérifie l'image toutes les N minutes et redémarre le site s'il y a du nouveau) : rien à ouvrir vers l'extérieur ;
   • ou un déploiement SSH depuis GitHub (docker compose pull && docker compose up -d) : immédiat, mais il faut une clé SSH en secret du dépôt.

Effets : plus de build sur le VPS (mémoire), chaque fusion en ligne en quelques minutes, et retour arrière simple (re-tagger une ancienne image).

Si l'idée te va, je prépare la partie GitHub (étape 1) dans une PR à part, et je te laisse la partie VPS. Sinon, cette PR reste un simple contrôle des PR.