# Notifications de déploiement, quelle que soit la CI

> Un push quand un déploiement échoue, une note discrète quand il réussit, depuis GitHub Actions, GitLab CI ou un simple script, avec la CLI honk-me.

Source: https://honk-me.app/fr/guides/notifications-deploiement

La plupart des CI savent signaler un pipeline en échec. Un déploiement, c’est autre chose : c’est le moment où la production change, et vous voulez en être informé où que vous soyez, bruyamment en cas d’échec, discrètement en cas de succès. La CLI `honk-me` s’en charge sur tout runner capable d’exécuter un binaire.

Le principe ne change pas d’un outil à l’autre. Un déploiement raté est un **problème** dans le groupe `deploy/<app>/<environment>`. Un déploiement réussi est un **rétablissement** de ce même groupe : après un échec, il clôt l’incident ; après un succès, il vous confirme simplement que tout s’est bien passé.

## Avant de commencer

- Un compte Honk (pour l’instant sur invitation : [demandez un accès](https://honk-me.app/fr/demander-un-acces)) et un projet dédié aux déploiements, avec une clé d’ingestion.
- `HONK_URL` et `HONK_KEY` enregistrés comme secrets dans votre CI.
- La CLI `honk-me` dans l’image de déploiement : `go install github.com/honk-me/honk-go/cmd/honk-me@latest`, ou un binaire depuis la [page des releases](https://github.com/honk-me/honk-go/releases).

## Un script de déploiement

Si vous déployez avec un script, un `trap` signale toute commande qui échoue, et la dernière ligne signale le succès :

```sh
#!/usr/bin/env bash
# deploy.sh: tell Honk when a deploy fails, and when it worked
set -euo pipefail
app=shop env=production rev=$(git rev-parse --short HEAD)

trap 'honk-me problem --group-key "deploy/$app/$env" --title "Deploy of $app failed" \
  --message "$rev failed at line $LINENO" --category deployments || true' ERR

./build.sh
./migrate.sh
./switch.sh

# a recovery closes a failed deploy's episode; after a good one it simply notifies
honk-me recovery --group-key "deploy/$app/$env" --title "Deployed $app $rev" \
  --message "to $env" --category deployments --idempotency-key "deploy-$app-$rev" || true
```

La clé d’idempotence associe l’app et la révision : le même déploiement lancé deux fois n’est signalé qu’une fois.

## GitLab CI

`after_script` s’exécute après le job, qu’il ait réussi ou échoué, et `CI_JOB_STATUS` indique son issue :

```yaml
deploy:
  stage: deploy
  script:
    - ./deploy.sh production
  after_script:
    - |
      if [ "$CI_JOB_STATUS" = "success" ]; then
        honk-me recovery --group-key "deploy/$CI_PROJECT_PATH/production" \
          --title "Deployed $CI_PROJECT_NAME" --message "$CI_COMMIT_SHORT_SHA to production" \
          --category deployments --idempotency-key "deploy-$CI_PIPELINE_ID-ok" || true
      else
        honk-me problem --group-key "deploy/$CI_PROJECT_PATH/production" \
          --title "Deploy failed: $CI_PROJECT_NAME" --message "$CI_PIPELINE_URL" \
          --category deployments --idempotency-key "deploy-$CI_PIPELINE_ID-failed" || true
      fi
```

## GitHub Actions

`if: always()` exécute l’étape dans tous les cas, et `job.status` indique comment le job s’est déroulé jusque-là :

```yaml
      - name: Tell Honk about the deploy
        if: always()
        env:
          HONK_URL: ${{ secrets.HONK_URL }}
          HONK_KEY: ${{ secrets.HONK_KEY }}
          STATUS: ${{ job.status }}
        run: |
          if [ "$STATUS" = "success" ]; then
            honk-me recovery --group-key "deploy/${{ github.repository }}/production" \
              --title "Deployed ${{ github.repository }}" --message "${{ github.sha }} to production" \
              --category deployments --idempotency-key "deploy-${{ github.run_id }}-${{ github.run_attempt }}" || true
          else
            honk-me problem --group-key "deploy/${{ github.repository }}/production" \
              --title "Deploy failed: ${{ github.repository }}" \
              --message "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
              --category deployments --idempotency-key "deploy-${{ github.run_id }}-${{ github.run_attempt }}" || true
          fi
```

La clé d’idempotence inclut le numéro de tentative : un **Re-run** est signalé comme un nouveau déploiement, alors que les nouvelles tentatives internes de la CLI ne créent jamais de doublon.

## Des déploiements réussis plus discrets

Un push par déploiement, c’est utile sur un projet calme, mais trop sur un projet très actif. Plutôt que de modifier le pipeline, ajoutez une règle au projet dans l’app web : si la catégorie est `deployments` et le type d’événement `recovery`, choisissez **Récapitulatif uniquement**. Les succès arrivent alors groupés toutes les 15 minutes, et un déploiement raté déclenche toujours un push immédiat.

## Pourquoi des rétablissements plutôt que de simples événements

Un simple événement « Déployé » créerait chaque fois son propre groupe, et un déploiement raté resterait ouvert dans « À traiter » jusqu’à devenir inactif, un jour plus tard. Signaler le succès comme un rétablissement clôt l’échec dès que le correctif est en ligne, et réunit tout l’historique d’une app et d’un environnement au même endroit.