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:
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.
export STATUS200_API_KEY="$CI_STATUS200_API_KEY"
export STATUS200_URL="https://status200.ru"
status200 incident countDai 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:
status200 --context production incident count
status200 --context staging monitor countCodici di uscita
| Codice | Significato | Per esempio |
|---|---|---|
0 | Ha funzionato | Un elenco, anche uno che non trova nulla |
1 | Non è riuscito | Status200 ha rifiutato la richiesta, come API error (422); JSON non valido; un'opzione mancante o sconosciuta; un contesto non salvato |
2 | Nessuna chiave API utilizzabile | Credenziali non trovate; una chiave API non valida; una chiave sotto il suo piano (402); 401 |
3 | Non trovato | Status200 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:
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 ;;
esacI 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:
# 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:
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ì:
{
"name": "Checkout API",
"monitorType": "Manual"
}status200 monitor create --file monitors/checkout-api.jsonMolti record da un array JSON, una creazione per ciascuno:
jq -c '.[]' monitors.json | while IFS= read -r monitor; do
status200 monitor create --data "$monitor" -o json | jq -r '._id'
doneOgni 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
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.shGitLab CI
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 0Docker
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:
docker build -t status200-cli .
docker run --rm -e STATUS200_API_KEY -e STATUS200_URL status200-cli incident count