Promotion Guard
Chaque build se termine par un contrôle de sécurité avant que le nouveau site ne remplace l'ancien : la promotion guard compare le build terminé au dernier bon build (sur le nombre de pages, les liens cassés, les marqueurs de contenu non résolus et les problèmes d'accessibilité) et refuse de publier un build qui ressemble à une régression. Le pire cas qu'elle autorise est une sortie périmée, jamais une sortie cassée.
Cette page explique ce qu'elle vérifie, comment la configurer, et comment forcer un build à la traverser.
Ce que la guard vérifie
Quatre verrous indépendants, évalués à chaque build et résumés dans un seul rapport :
| Vérification | Ce qu'elle compare | Seuil par défaut |
|---|---|---|
| Chute du nombre de pages | Fichiers dans le build terminé vs la dernière promotion bonne | Une chute de plus de 80 % bloque |
| Liens internes cassés | Augmentation vs le compte stocké à la dernière promotion propre | Une augmentation de plus de 25 |
| Marqueurs de block non résolus | Compte absolu des commentaires <!-- block not found --> dans la sortie | Désactivé jusqu'à ce que vous fixiez la limite (0 signifie « pas même un ») |
| Problèmes d'accessibilité | Augmentation vs la dernière promotion propre (images sans texte alt, lang manquant, liens vides, plusieurs H1 par page) | Une augmentation de plus de 10 |
Pourquoi des deltas plutôt que des absolus pour deux des quatre : les comptes absolus s'adaptent naturellement à la taille de votre site (chaque page peut partager un lien ou un style d'image), donc ce qui compte est un bond soudain, pas un total en régime établi. Une base de nombre de pages qui a dérivé vers le bas ne s'applique plus non plus ; les builds échoués et bloqués ne la définissent jamais, et un « promote anyway » ne la réinitialise pas non plus. Le point de comparaison est toujours le dernier build que la guard a laissé passer proprement, donc on ne peut pas amener la guard à tolérer une lente dérive.
Les trois modes
Sous Settings → Workflow :
- Warn (par défaut): un build qui enfreint un seuil est quand même promu, mais une ligne d'avertissement claire est écrite dans le log de build : ce qui a enfreint, de combien, et quel était la limite. Idéal tant que vous apprenez ce que la guard voit sur votre site.
- Enforce: un build en infraction n'est pas publié : la copie de staging est jetée et le site en ligne précédent continue de servir. Le log de build enregistre le résultat comme blocked, avec le motif et les comptages de qualité, et le dashboard affiche une bannière Promotion Blocked.
- Off: aucune guard ne tourne. Déconseillé comme réglage permanent ; utilisez « Warn » à la place si la guard est bruyante.
Les seuils sont bornés à des valeurs saines à l'enregistrement (le pourcentage de chute 0-100 ; les autres entiers non négatifs). Le verrou des marqueurs non résolus démarre désactivé sur les sites mis à niveau pour qu'une mise à niveau de routine ne bloque jamais soudainement des builds pour un vieux bug de contenu ; fixez un nombre (même 0) pour l'activer délibérément.
Quand un build est bloqué
- Le panneau de statut du dashboard passe en Promotion blocked avec le motif, et un bouton Promote anyway apparaît, mais seulement dans cet état, et seulement pour les admins.
- Le site construit n'est pas montré : tout ce qui se trouve dans le candidat échoué est jeté proprement, et le site en ligne ne sert jamais une promotion à moitié faite.
- L'historique des builds conserve la tentative échouée avec son log complet et les comptages de qualité, pour que vous puissiez voir exactement ce qui a régressé (un crash de page, un template cassé produisant du bruit de liens manquants, une masse de pages non publiées) avant de décider.
- Un build bloqué est un avertissement sur vos changements, pas une faute du système : la cause classique est de publier un build alors qu'un template cassé ou un mauvais brouillon est en ligne.
Promote anyway (la soupape d'échappement)
Si un build est bloqué et que vous êtes certain qu'il est correct (par exemple, vous avez délibérément supprimé un tiers du site), cliquez sur Promote anyway sur le dashboard (ou, pour les builds scriptés, CHINASKI_FORCE_PROMOTE=1 perl builder/build.pl) :
- La guard est contournée pour ce seul build ; le prochain build normal relance tous les contrôles.
- Le contournement ne rafraîchit pas les bases de qualité. C'est délibéré : forcer de mauvais chiffres dans la base ferait de la même régression une « norme » ignorée sur les builds futurs. Le prochain build régulier compare toujours à la dernière promotion propre, donc la régression reste visible jusqu'à sa correction.
- Le bouton de contournement du dashboard n'apparaît que pendant qu'un build est bloqué ; les contrôles supplémentaires restent actifs : la soupape d'échappement est à usage unique, et le log le consigne.
Configurer la guard
| Réglage (Settings → Workflow) | Champ | Effet |
|---|---|---|
| Guard mode | Warn / Enforce / Off | Les infractions avertissent ou bloquent |
| Page-drop threshold | percent | Combien de fichiers un build peut perdre avant que la guard ne parle |
| Broken-link increase | integer | Croissance maximale vs la dernière promotion propre |
| Unresolved block markers | vide/nombre | Vide = verrou désactivé ; un nombre (même 0) = limite stricte sur les intégrations de blocks manquants |
| A11y issue increase | integer | Croissance maximale des problèmes d'accessibilité vs la dernière promotion propre |
Les seuils sont par instance. Si vous voyez des avertissements fréquents sur un site sain, consultez d'abord le rapport d'infractions ; la guard vous dit exactement quel verrou a déclenché et de combien, et chaque seuil a une valeur par défaut sûre qui convient à la plupart des sites.
Cas de guard désactivée (promotions sans comparaison)
- Guard mode réglé sur Off.
- Un build forcé (la soupape d'échappement ci-dessus).
- Le premier build après un démarrage frais (rien à quoi comparer encore ; le rapport de qualité est quand même produit).
- Les deltas de liens cassés et d'a11y quand aucune base précédente n'existe (premier build, ou bases antérieures aux données) ; ces verrous s'éveillent dès qu'une promotion propre a stocké des chiffres de base.
Les petites lignes
- Le verrou « page count » compte les fichiers écrits par le build, ce qui inclut les petits fichiers de support aussi bien que les pages de contenu, donc les très petits builds (sites de trois pages) ont proportionnellement plus de sensibilité. La valeur par défaut de 80 % absorbe cela.
- Les builds incrémentaux reçoivent la même guard que les complets : le staging est de toute façon une copie complète du site, donc les comptages restent comparables.
- La guard ne change jamais la sortie elle-même ; elle ne peut qu'avancer ou jeter la copie de staging.