# Notificări de deploy din orice CI

> O notificare când un deploy eșuează și o notă discretă când reușește, din GitHub Actions, GitLab CI sau un script de deploy, cu CLI-ul honk-me.

Source: https://honk-me.app/ro/ghiduri/notificari-deploy

Majoritatea sistemelor de CI te anunță când un pipeline eșuează. Un deploy e altceva: e momentul în care se schimbă producția, iar despre el vrei să afli oriunde ai fi, cu eșecurile anunțate tare și succesele, discret. CLI-ul `honk-me` face asta în orice runner care poate rula un binar.

Modelul e același peste tot. Un deploy eșuat e o **problemă** în grupul `deploy/<app>/<environment>`. Un deploy reușit e o **revenire** în același grup: după un eșec, închide incidentul, iar după un deploy bun îți spune doar că a mers.

## Înainte să începi

- Un cont Honk (deocamdată, doar pe bază de invitație: [cere acces](https://honk-me.app/ro/cere-acces)) și un proiect pentru deploy-uri, cu o cheie API.
- `HONK_URL` și `HONK_KEY` ca secrete în CI.
- CLI-ul `honk-me` în imaginea de deploy: `go install github.com/honk-me/honk-go/cmd/honk-me@latest` sau un binar de pe [pagina Releases](https://github.com/honk-me/honk-go/releases).

## Un script de deploy

Dacă faci deploy cu un script, un `trap` raportează orice linie care eșuează, iar ultima linie raportează succesul:

```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
```

Cheia de idempotență e formată din aplicație și revizie, deci același deploy rulat de două ori e raportat o singură dată.

## GitLab CI

`after_script` rulează după job, indiferent dacă a trecut sau a eșuat, iar `CI_JOB_STATUS` îți spune cum s-a terminat:

```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()` rulează pasul în orice caz, iar `job.status` îți spune cum a mers jobul până acolo:

```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
```

Cheia de idempotență include numărul încercării: un **Re-run** e raportat ca deploy nou, iar reîncercările făcute de CLI nu dublează niciodată un deploy.

## Deploy-uri reușite, mai discrete

O notificare pentru fiecare deploy e utilă pe un proiect liniștit, dar e prea mult pe unul aglomerat. Nu trebuie să schimbi pipeline-ul: adaugă o regulă în proiect, din aplicația web. Când categoria este `deployments` și tipul evenimentului este `recovery`, la **Notificări** alegi **Doar în rezumat**. Deploy-urile reușite vin apoi adunate la fiecare 15 minute, iar unul eșuat te anunță în continuare imediat.

## De ce reveniri și nu evenimente simple

Un simplu eveniment „Deploy reușit” ar ajunge de fiecare dată în alt grup, iar un deploy eșuat ar rămâne în Atenție până ar deveni inactiv, o zi mai târziu. Dacă raportezi succesul ca revenire în grupul deploy-ului, eșecul se închide în clipa în care corecția ajunge în producție, iar tot istoricul unei aplicații într-un mediu stă într-un singur loc.