# Avisos de despliegue desde cualquier CI

> Recibe una alerta cuando falla un despliegue y un aviso tranquilo cuando sale bien, desde GitHub Actions, GitLab CI o un script propio, con la CLI honk-me.

Source: https://honk-me.app/es/guias/notificaciones-despliegue

Casi cualquier sistema de CI te avisa si falla un pipeline. Un despliegue es otra cosa: es el momento en que cambia producción, y quieres saberlo estés donde estés, con los fallos bien a la vista y los éxitos sin hacer ruido. La CLI `honk-me` lo hace en cualquier runner capaz de ejecutar un binario.

El patrón es siempre el mismo. Un despliegue fallido es un **problema** en el grupo `deploy/<app>/<environment>`. Uno correcto es una **recuperación** en ese mismo grupo: si antes hubo un fallo, cierra el incidente; si no, simplemente te confirma que salió bien.

## Antes de empezar

- Una cuenta de Honk (por ahora solo con invitación: [solicita acceso](https://honk-me.app/es/solicitar-acceso)) y un proyecto para los despliegues, con una clave de ingesta.
- `HONK_URL` y `HONK_KEY` como secretos en tu CI.
- La CLI `honk-me` en la imagen de despliegue: `go install github.com/honk-me/honk-go/cmd/honk-me@latest`, o un binario de la [página de releases](https://github.com/honk-me/honk-go/releases).

## Un script de despliegue

Si despliegas con un script, un `trap` avisa de cualquier línea que falle y la última línea confirma el éxito:

```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 clave de idempotencia combina la app y la revisión: si lanzas dos veces el mismo despliegue, solo se notifica una vez.

## GitLab CI

`after_script` se ejecuta al terminar el trabajo, haya salido bien o mal, y `CI_JOB_STATUS` indica cuál de las dos:

```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()` ejecuta el paso en cualquier caso, y `job.status` indica cómo ha ido el trabajo hasta ese momento:

```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 clave de idempotencia incluye el número de intento, así que **Re-run** cuenta como un despliegue nuevo, mientras que los reintentos de la propia CLI nunca lo duplican.

## Despliegues correctos, con menos ruido

Una notificación por despliegue viene bien en un proyecto tranquilo, pero es demasiado en uno con mucha actividad. En lugar de tocar el pipeline, añade una regla al proyecto en la app web: si la categoría es `deployments` y el tipo de evento es `recovery`, elige **Solo resumen** en las notificaciones. Los éxitos llegarán agrupados cada 15 minutos, y un despliegue fallido seguirá avisando al instante.

## Por qué recuperaciones y no eventos normales

Un simple evento «Desplegado» acabaría cada vez en un grupo distinto, y un despliegue fallido seguiría abierto en Atención hasta quedar inactivo un día después. Si notificas el éxito como recuperación del grupo del despliegue, el fallo se cierra en cuanto la corrección llega a producción, y todo el historial de una app y un entorno queda en un solo sitio.