Bloquer un merge sur PostShip

PostShip publie un Check nommé PostShip sur le commit de chaque déploiement vérifié (Connecter GitHub). GitHub sait s'en servir comme d'une condition de fusion : c'est le même mécanisme que vos tests. Cette page dit comment l'exiger, ce qui le fait passer au rouge, et comment durcir la règle avec un score plancher.

Exiger le Check sur GitHub

1. Ouvrez le dépôt sur GitHub, onglet Settings.
2. Branches → Add branch protection rule (ou modifiez la règle existante).
3. Branch name pattern : main, ou votre branche par défaut.
4. Cochez Require status checks to pass before merging.
5. Dans la liste, cherchez PostShip et sélectionnez-le. Le Check doit être apparu au moins une fois pour figurer dans la liste : déployez une fois si besoin.
6. Enregistrez. Une pull request dont le Check est rouge ne peut plus être fusionnée.

Pour que le Check tombe sur la pull request avant la fusion, il faut que les previews soient vérifiées (Previews) : c'est le Check de la preview qui bloque le merge. Le Check de production, lui, arrive après coup et sert de trace.

Ce qui fait rougir le Check

Le réglage vit sur la carte GitHub de Projet → Intégrations, sous forme d'un bouton à bascule :

Le second réglage existe parce qu'une carte sociale cassée ne mérite pas d'arrêter une équipe ; un checkout cassé, si. Il s'applique aussi aux previews : sans cela, une image Open Graph manquante sur une preview faisait rougir le Check de chaque pull request.

Le titre du Check nomme ce qui a fait rougir, et rien d'autre — une raison affichée sur chaque exécution verte n'est plus une raison :

• PostShip · 92 — vert, ou rouge en mode « ship vert » avec au moins un échec.
• PostShip · 92 (pack argent) — rouge, mode « pack argent », une page argent est tombée.
• PostShip · 71 (seuil 80) — rouge, Team, score sous le plancher.
• PostShip · 100 (déployé pendant le gel : pas de prod le week-end) — rouge, le déploiement est arrivé pendant un gel. Le gel prime sur tout : un ship parfait déployé pendant le gel est exactement ce que la règle voulait empêcher.

Le score plancher

Le réglage est dans Projet → Paramètres → Règles, carte Score plancher du Check GitHub : un champ Seuil (0–100), à 80 par défaut. Sous ce score, le Check passe en échec même si aucune URL ne renvoie d'erreur, quel que soit le mode choisi ci-dessus. Le plancher n'est comparé qu'au score de production ; une preview n'a pas de score.

Côté hébergeur

• Vercel sait retenir la promotion en production tant qu'un check externe n'est pas vert (Deployment Checks, https://vercel.com/docs/deployment-checks). Si votre projet Vercel est relié au dépôt GitHub, la protection de branche ci-dessus suffit déjà : une pull request rouge ne peut pas être fusionnée, donc rien ne part en production.
• Netlify pose le même Check, sur les previews comme en production.
• Cloudflare Pages et le webhook générique ne publient pas de Check : rien à exiger côté GitHub pour eux.

Limites et plans

Dépannage

Pourquoi PostShip n'apparaît pas dans la liste des status checks ?

GitHub ne propose que les checks déjà vus sur le dépôt. Déployez une fois avec GitHub connecté, puis revenez dans la règle de protection. Si le Check n'apparaît toujours pas, le dépôt enregistré sur la carte n'est pas celui-ci.

Pourquoi le Check est vert alors qu'une page a échoué ?

Vous êtes en mode Ne bloquer que sur le pack argent et la page tombée n'est pas une page argent. Le titre dit alors, sur une preview, « … en échec, hors pack argent ». Basculez sur Exiger un ship vert pour merger si tout doit bloquer.

Pourquoi le Check bloque la pull request alors que la production est saine ?

C'est le Check de la preview qui bloque, et il est posé sur le commit de la pull request. Ouvrez-le : le résumé nomme la page en échec sur l'hôte de preview. Une route qui a bougé casse sur la preview avant de casser en production — c'est la raison d'être de la preview.

Pourquoi le plancher n'est pas appliqué ?

Il ne l'est qu'en Team. Sous Team, la carte l'indique : « Sans plan Team, le Check reste purement informatif ».