Vai al contenuto
Scripting e CI/CD

Scripting e CI/CD

La CLI funziona in uno script come in un terminale. Dalle una chiave API in variabili d'ambiente, leggi le sue risposte come JSON e lascia che il suo codice di uscita dica allo script che cosa è successo. Questa pagina mostra ciascuna di queste cose, e pipeline complete per GitHub Actions, GitLab CI e Docker.

Come uno script usa la CLI

Un deployment può prima chiedere a Status200 se c'è un incidente aperto, e fermarsi se ce n'è uno:

flowchart TB J["Il job di CI parte"] --> S["I suoi secret impostano<br/>STATUS200_API_KEY<br/>e STATUS200_URL"] S --> Q["status200 incident count<br/>degli incidenti non risolti"] Q -->|"0"| D["Esegui il<br/>deployment"] Q -->|"1 o più"| X["Fermati:<br/>c'è un incidente<br/>aperto"] Q -->|"codice di<br/>uscita 2"| A["Fermati:<br/>controlla la<br/>chiave API"]

Un deployment che aspetta finché c'è un incidente aperto

Dare a uno script la sua chiave API

Imposta STATUS200_API_KEY e STATUS200_URL dai secret del tuo sistema di CI. La CLI allora non ha bisogno né di login né di un file di configurazione. Un flag viene ancora prima di loro per un singolo comando, e loro vengono prima dei contesti salvati.

Bash
export STATUS200_API_KEY="$CI_STATUS200_API_KEY"
export STATUS200_URL="https://status200.ru"
status200 incident count
Suggerimento

Dai a ogni pipeline una chiave API tutta sua, con solo l'accesso che le serve: un controllo che si limita a leggere ha bisogno di una chiave che si limita a leggere. Elimina la chiave in Status200 quando la pipeline viene dismessa.

Se una macchina esegue job per più progetti, salva un contesto per ciascuno e indicalo in ogni comando, così un job non usa mai il contesto attuale di un altro:

Bash
status200 --context production incident count
status200 --context staging monitor count

Codici di uscita

CodiceSignificatoPer esempio
0Ha funzionatoUn elenco, anche uno che non trova nulla
1Non è riuscitoStatus200 ha rifiutato la richiesta, come API error (422); JSON non valido; un'opzione mancante o sconosciuta; un contesto non salvato
2Nessuna chiave API utilizzabileCredenziali non trovate; una chiave API non valida; una chiave sotto il suo piano (402); 401
3Non trovatoStatus200 ha risposto 404: il record non esiste, si trova in un altro progetto, oppure la chiave non può leggerlo

whoami e context current terminano con 0 anche quando non è salvato nulla: riferiscono che cosa è impostato, non lo verificano. Uno script distingue i casi dal codice:

Bash
status200 incident get "$INCIDENT_ID" -o json > incident.json
case $? in
  0) echo "Saved the incident to incident.json" ;;
  2) echo "Check STATUS200_API_KEY and STATUS200_URL" >&2; exit 1 ;;
  3) echo "There is no incident $INCIDENT_ID" >&2; exit 1 ;;
  *) echo "Status200 refused the request" >&2; exit 1 ;;
esac

I messaggi di errore vanno sullo standard error, quindi incident.json contiene solo la risposta.

Leggere le risposte con jq

Scrivi -o json negli script. In una pipe la CLI stampa comunque JSON, ma il flag fa funzionare lo script ovunque giri:

Bash
# The title of each incident
status200 incident list -o json | jq -r '.[].title'

# The ID of a new monitor
MONITOR_ID=$(status200 monitor create --data '{"name":"Checkout API","monitorType":"Manual"}' -o json | jq -r '._id')

# When each incident was created: dates come as objects
status200 incident list -o json | jq -r '.[] | "\(.createdAt.value)  \(.title)"'

# The newest 100 incidents as CSV
status200 incident list --limit 100 -o json | jq -r '.[] | [._id, .title, .createdAt.value] | @csv'

Un conteggio stampa un solo numero, pronto per il confronto:

Bash
OPEN=$(status200 incident count --query '{"currentIncidentState":{"isResolvedState":false}}')
echo "$OPEN incidents are open"

Creare record da file

Tieni i record come file JSON accanto al tuo codice, e creali da lì:

monitors/checkout-api.jsonJSON
{
  "name": "Checkout API",
  "monitorType": "Manual"
}
Bash
status200 monitor create --file monitors/checkout-api.json

Molti record da un array JSON, una creazione per ciascuno:

Bash
jq -c '.[]' monitors.json | while IFS= read -r monitor; do
  status200 monitor create --data "$monitor" -o json | jq -r '._id'
done
Nota

Ogni esecuzione crea nuovi record. Per mantenere monitor e pagine di stato allineati ai file, modificare solo ciò che è cambiato e rimuovere ciò che non c'è più, usa il provider Terraform.

Esempi di pipeline

GitHub Actions

.github/workflows/deploy.ymlYAML
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: lts/*
      - name: Install the Status200 CLI
        run: npm install -g @status200/cli
      - name: Stop while an incident is open
        env:
          STATUS200_API_KEY: ${{ secrets.STATUS200_API_KEY }}
          STATUS200_URL: https://status200.ru
        run: |
          OPEN=$(status200 incident count --query '{"currentIncidentState":{"isResolvedState":false}}')
          if [ "$OPEN" -gt 0 ]; then
            echo "$OPEN incidents are open: not deploying."
            exit 1
          fi
      - name: Deploy
        run: ./deploy.sh

GitLab CI

.gitlab-ci.ymlYAML
check-incidents:
  stage: test
  image: node:lts
  variables:
    STATUS200_URL: https://status200.ru
  script:
    - npm install -g @status200/cli
    - OPEN=$(status200 incident count --query '{"currentIncidentState":{"isResolvedState":false}}')
    - echo "$OPEN incidents are open"
    - test "$OPEN" -eq 0

Docker

DockerfileDockerfile
FROM node:lts-slim
RUN npm install -g @status200/cli
ENTRYPOINT ["status200"]

In GitHub Actions, aggiungi STATUS200_API_KEY in Settings → Secrets and variables → Actions del repository; in GitLab, aggiungila come variabile CI/CD mascherata. Con l'immagine Docker, passa le variabili a ogni esecuzione:

Bash
docker build -t status200-cli .
docker run --rm -e STATUS200_API_KEY -e STATUS200_URL status200-cli incident count

Passi successivi