Vérifier depuis votre CI

Le Check GitHub arrive après le déploiement. L'API, elle, tourne quand vous le décidez : avant un merge, après un build, sur une preview. Même moteur, mêmes vérifications, même Ship Score. Rien à installer : un appel HTTP avec curl, et jq pour lire la réponse — les deux sont déjà sur les runners GitHub.

Le jeton

Paramètres → API & tokens → Créer un jeton. Il n'est affiché qu'une fois : PostShip n'en garde que l'empreinte et ne peut pas vous le redonner. Perdu, on le révoque et on en frappe un autre. Cinq jetons actifs au maximum. Voir Jetons.

Mettez-le dans un secret de votre CI (GitHub : Settings → Secrets and variables → Actions ; GitLab : Settings → CI/CD → Variables, masquée et protégée). Il passe par une variable d'environnement, jamais en argument d'une commande : les CI masquent les secrets dans les logs, mais un argument se retrouve dans la liste des processus du runner, où le masquage ne s'applique pas.

L'appel

export POSTSHIP_TOKEN=psk_…

curl -sS -X POST https://postship.fr/api/v1/check \
  -H "Authorization: Bearer $POSTSHIP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://votre-site.fr"}'

La réponse porte outcome (pass ou fail), score, reason, checks[] et quota — chaque champ est décrit dans la référence de la route. Faites échouer votre étape sur un outcome autre que pass, ou sur un score sous votre seuil.

Les codes de sortie, et pourquoi 1 n'est pas 2

Un site qui a un problème et un outil qui n'a pas pu se prononcer ne sont pas la même chose. Un workflow qui bloque une fusion sur l'état du site sans bloquer sur une panne de PostShip ne peut faire la différence que par le code de sortie : 1 dit « le site a un problème », 2 dit « la vérification n'a pas eu lieu » — jeton refusé, quota atteint, PostShip injoignable. Le script ci-dessous fait cette distinction et applique un score plancher.

set -u
MIN_SCORE="${MIN_SCORE:-80}"
response=$(curl -sS -w '\n%{http_code}' -X POST https://postship.fr/api/v1/check \
  -H "Authorization: Bearer $POSTSHIP_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"url\":\"$URL\"}") || exit 2
status=$(printf '%s' "$response" | tail -n1)
body=$(printf '%s' "$response" | sed '$d')
echo "$body"
if [ "$status" != "200" ]; then
  echo "PostShip n'a pas pu vérifier ($status) : $(echo "$body" | jq -r .error)"
  exit 2
fi
outcome=$(echo "$body" | jq -r .outcome)
score=$(echo "$body" | jq -r .score)
if [ "$outcome" != "pass" ]; then
  echo "$body" | jq -r '.checks[] | select(.outcome != "pass") | "\(.label) : \(.detail)"'
  exit 1
fi
if [ "$score" -lt "$MIN_SCORE" ]; then
  echo "Ship Score $score sous le seuil $MIN_SCORE ($(echo "$body" | jq -r .reason))"
  exit 1
fi

Sur GitHub Actions, un code autre que 0 fait échouer l'étape dans les deux cas ; ajoutez continue-on-error: true sur l'étape et testez steps.<id>.outcome si vous voulez laisser passer un code 2. Le seuil se règle par la variable MIN_SCORE — c'est le même chiffre que le score plancher du Check GitHub, appliqué ici avant la fusion plutôt qu'après le déploiement.

Quota

Les vérifications de CI sont comptées par mois et par compte : 30 en Free, 300 en Pro, 1000 en Team. Au-delà, l'appel est refusé (429) avec le compte exact — jamais un résultat dégradé : une CI qui ment est pire qu'une CI qui casse. Le compteur du mois est affiché dans Paramètres → API & tokens. Voir les plans.

Dépannage

Pourquoi l'étape échoue-t-elle avec « Jeton d'API invalide ou révoqué » ?

Le secret n'est pas exposé à ce job (sur GitHub, un workflow déclenché par une pull request d'un fork n'a pas accès aux secrets), ou le jeton a été révoqué. Vérifiez la date de dernière utilisation du jeton dans Paramètres → API & tokens.

Pourquoi vérifier l'URL de preview plutôt que la production ?

Parce que c'est avant la fusion que le verdict est utile. L'événement deployment_status de GitHub porte l'URL de la preview dans target_url ; sur Vercel, Netlify ou Cloudflare Pages, PostShip peut aussi vérifier les previews sans passer par votre CI.

Pourquoi le score de la CI diffère-t-il de celui de mon projet ?

La CI vérifie une URL nue, sans les assertions du pack argent ni les contrôles du site. Le projet, lui, note tout ce qu'il surveille.