Votre déploiement est une carte, pas cinq alertes

Un déploiement a cinq étapes, donc un pipeline naïf vous envoie cinq notifications. À la troisième vous avez coupé le canal, et le jour où quelque chose échoue vraiment, l'échec est enterré entre un ping de checkout et un ping de build qui n'ont jamais compté.

Les notifications de workflow replient tout le processus en une carte. Chaque POST qui porte le même runId met à jour la même alerte : les étapes se remplissent en direct, la carte passe au vert ou au rouge à la fin, et votre téléphone vibre exactement deux fois, au départ du run et à son arrivée.

Un runId, autant de POST que vous voulez

Envoyez le tableau d'étapes complet à chaque POST, Zenhook remplace le contenu de la carte à chaque fois. Le premier POST d'un nouveau runId crée la carte et vous notifie.

curl -X POST "$ZENHOOK_URL" -H "Content-Type: application/json" -d '{
  "title": "api deploy",
  "workflow": {
    "runId": "deploy-8f2c41",
    "state": "running",
    "steps": [
      { "name": "checkout", "state": "done", "seconds": 4 },
      { "name": "gate",     "state": "done", "seconds": 81, "info": "512 tests" },
      { "name": "build",    "state": "running" },
      { "name": "deploy",   "state": "pending" },
      { "name": "verify",   "state": "pending" }
    ]
  }
}'

curl -X POST "$ZENHOOK_URL" -H "Content-Type: application/json" -d '{
  "title": "api deploy",
  "level": "success",
  "workflow": {
    "runId": "deploy-8f2c41",
    "state": "passed",
    "steps": [ /* all five, state done, with seconds */ ]
  }
}'

Le POST final bascule la carte sur son résultat et vous notifie une dernière fois. Deux notifications pour tout le run, quel que soit le nombre d'étapes. Les mises à jour d'un run existant ne sont pas facturées comme de nouveaux événements.

L'échec porte son propre contexte

Quand une étape échoue, mettez la fin du log dans le champ error du workflow : elle s'affiche sur la carte, donc l'alerte sur votre téléphone suffit à diagnostiquer sans ouvrir un ordinateur. Les mises à jour dans le désordre sont gérées aussi : un POST running en retard qui arrive après le résultat, un retry par exemple, ne peut jamais rétrograder une carte terminée.

La même carte partout

La carte s'affiche sur le web, iOS et Android avec le même contrat, et le flux web épingle les runs actifs au-dessus des groupes par jour. Si votre pipeline sait envoyer un POST HTTP, il peut avoir ça : pas de SDK, pas de plugin CI.