Connecter GitHub

Une fois GitHub connecté, PostShip publie un Check Run sur le commit déployé après chaque vérification déclenchée par un webhook de déploiement : vert si tout passe, rouge sinon, avec le Ship Score en titre et le détail par URL en résumé. Vous voyez le verdict dans la pull request sans quitter GitHub — et vous pouvez en faire une condition de fusion (bloquer un merge).

Prérequis

Le Check se rattache au commit du déploiement. Il faut donc qu'un webhook qui apporte ce commit soit branché :

Installer l'app GitHub (recommandé)

Rien à créer, rien à faire tourner, et la révocation se fait d'un clic côté GitHub. Aucun secret n'est stocké chez PostShip : l'app obtient un jeton d'une heure à chaque Check Run.

1. Sur Projet → Déploiements → Réglages, section Check GitHub, cliquez sur Connecter GitHub.
2. Sur l'écran GitHub, choisissez le compte ou l'organisation, puis Only select repositories et le dépôt du site surveillé. Les permissions demandées sont Checks : Read and write et Pull requests : Read and write — la seconde sert uniquement au commentaire de preview sur la pull request (plus Metadata : Read-only, que GitHub ajoute seul). PostShip ne lit jamais votre code.
3. Autorisez : GitHub vous ramène sur PostShip. La carte affiche « App installée — choisissez le dépôt à surveiller » : sélectionnez-le dans la liste et enregistrez. La carte passe à Connecté.

Si le dépôt appartient à une organisation

GitHub peut exiger l'accord d'un propriétaire. L'installation part alors en demande d'approbation et PostShip vous le dit ; la connexion se termine une fois la demande acceptée, en relançant Connecter GitHub.

Avec un token, à la place

L'ancien chemin reste supporté, replié sous Utiliser un token à la place, pour qui préfère un jeton qu'il contrôle.

1. Sur GitHub : Settings → Developer settings → Personal access tokens → Fine-grained tokens, limité au dépôt concerné, avec la permission Checks en Read and write — aucune autre.
2. Sur la carte, renseignez le dépôt au format owner/repo et collez le jeton (github_pat_…), puis Enregistrer. Il est chiffré et jamais réaffiché.

Ce que le Check contient

• Nom : PostShip. C'est ce nom que la protection de branche cherche.
• Titre : PostShip · 92, le Ship Score. Suivi de la raison quand le Check est rouge : (seuil 80), (pages de paiement), (déployé pendant le gel : …).
• Résumé : une ligne par URL vérifiée, les échecs décrits comme dans une alerte, et la ligne des liens de la page d'accueil.
• Sur une preview : Preview vérifiée, ou Preview : 2 pages en échec — sans score, parce que la moitié de ce qui le compose n'a pas de sens sur un hôte *.vercel.app.

Ce qui fait passer le Check au rouge est réglable sur la carte : Exiger un déploiement vert pour merger (le défaut) ou Ne bloquer que sur les pages de paiement. Le détail est sur Bloquer un merge.

Se déconnecter

Déconnecter GitHub retire le dépôt et l'identifiant d'installation du projet. Pour retirer l'app elle-même de votre compte GitHub : Settings → Applications → Installed GitHub Apps.

Limites et plans

Le Check est compris dans tous les plans : il suit les webhooks de déploiement, que Découverte reçoit aussi. Le score plancher, lui, est réservé à Pro Plus. Voir les plans.

Dépannage

Pourquoi aucun Check n'apparaît sur mes commits ?

3 causes, dans l'ordre : le déploiement ne portait pas de commit (déploiement lancé depuis un terminal, Cloudflare, webhook générique) ; le dépôt enregistré n'est pas celui d'où part le déploiement ; l'app n'a plus accès au dépôt (retiré de l'installation). La carte ne le signale pas : un Check qui n'a pas pu être posé ne fait jamais échouer le webhook.

Pourquoi « Rattachement GitHub indisponible » ?

PostShip ne peut pas, sur ce site, vérifier que l'installation vous appartient (l'app GitHub n'est pas entièrement configurée côté serveur). Les projets déjà rattachés continuent de recevoir leurs Check Runs ; utilisez le token en attendant.

Pourquoi « Cette installation GitHub est déjà rattachée à un autre compte PostShip » ?

Une installation ne se rattache qu'à un seul compte — un collègue de la même organisation l'a prise, le plus souvent. Demandez-lui de la détacher (Déconnecter GitHub sur son projet), de vous inviter sur son projet, ou installez l'app sur un autre compte GitHub. « Cette installation GitHub n'est pas la vôtre » signifie que votre compte GitHub n'a pas accès à l'installation choisie.

Bloquer un merge sur PostShip

Faire du Check PostShip une condition de fusion, choisir ce qui le fait rougir, et poser un score plancher.

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 dans la section Check GitHub de Projet → Déploiements → Réglages, 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 (pages de paiement) — rouge, mode « pages de paiement », une page de paiement est tombée.
• PostShip · 71 (seuil 80) — rouge, Pro Plus, 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 → Déploiements → Réglages, 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.

Le Ship Gate : la prod attend l'argent

Sans dépôt GitHub, ou pour un déploiement lancé à la main, il reste ce que Vercel appelle un contrôle bloquant. Projet → Déploiements → Réglages → Ship Gate → Ne pas publier si le parcours de paiement casse : dès qu'un déploiement de production est créé, PostShip pose un contrôle bloquant chez Vercel ; une fois le déploiement construit, il vérifie l'accueil et les pages des pages de paiement (tarifs, connexion, checkout, Stripe.js) sur l'adresse unique du déploiement — pas sur votre domaine, qui sert encore l'ancienne version — et conclut. Tout vert : Vercel assigne le domaine. Une page de paiement en échec : le site d'avant reste en ligne, et le journal du projet dit pourquoi. C'est le contraire d'un ping de la home : on retient le ship.

Il faut l'intégration Vercel (pas le webhook collé à la main) et, côté Vercel, la capacité Checks activée sur l'intégration. Une carte sociale ou un formulaire secondaire cassés ne retiennent pas un ship. Si PostShip lui-même ne peut pas vérifier, la promotion est libérée, et le journal le dit : notre panne ne doit pas retenir votre site. Vercel seulement — Netlify et Cloudflare Pages n'ont pas d'API équivalente. Pro et au-delà.

• 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 les pages de paiement et la page tombée n'est pas une page de paiement. Le titre dit alors, sur une preview, « … en échec, hors pages de paiement ». Basculez sur Exiger un déploiement 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 Pro Plus. Sous Pro Plus, la carte l'indique : « Sans plan Pro Plus, le Check reste purement informatif ».