Skripting & CI/CD
Die CLI arbeitet in einem Skript genauso wie im Terminal. Geben Sie ihr einen API-Schlüssel in Umgebungsvariablen, lesen Sie ihre Antworten als JSON und lassen Sie ihren Exit-Code dem Skript sagen, was passiert ist. Diese Seite zeigt jedes davon und vollständige Pipelines für GitHub Actions, GitLab CI und Docker.
Wie ein Skript die CLI verwendet
Ein Deployment kann Status200 zuerst fragen, ob ein Vorfall offen ist, und anhalten, wenn einer offen ist:
Ein Deployment, das wartet, solange ein Vorfall offen ist
Einem Skript seinen API-Schlüssel geben
Setzen Sie STATUS200_API_KEY und STATUS200_URL aus den Secrets Ihres CI-Systems. Die CLI braucht dann kein login und keine Konfigurationsdatei. Ein Flag geht ihnen für einen einzelnen Befehl weiterhin vor, und sie gehen gespeicherten Kontexten vor.
export STATUS200_API_KEY="$CI_STATUS200_API_KEY"
export STATUS200_URL="https://status200.ru"
status200 incident countGeben Sie jeder Pipeline einen eigenen API-Schlüssel mit nur dem Zugriff, den sie braucht: Eine Prüfung, die nur liest, braucht einen Schlüssel, der nur liest. Löschen Sie den Schlüssel in Status200, wenn die Pipeline außer Dienst geht.
Führt ein Rechner Jobs für mehrere Projekte aus, speichern Sie für jedes einen Kontext und nennen Sie ihn in jedem Befehl, damit ein Job nie den aktuellen Kontext eines anderen verwendet:
status200 --context production incident count
status200 --context staging monitor countExit-Codes
| Code | Bedeutung | Zum Beispiel |
|---|---|---|
0 | Es hat geklappt | Eine Liste, auch eine, die nichts findet |
1 | Es ist fehlgeschlagen | Status200 hat die Anfrage abgelehnt, etwa mit API error (422); ungültiges JSON; eine fehlende oder unbekannte Option; ein Kontext, der nicht gespeichert ist |
2 | Kein verwendbarer API-Schlüssel | Keine Anmeldedaten gefunden; ein ungültiger API-Schlüssel; ein Schlüssel unter seinem Tarif (402); 401 |
3 | Nicht gefunden | Status200 hat mit 404 geantwortet: Der Datensatz existiert nicht, liegt in einem anderen Projekt, oder der Schlüssel darf ihn nicht lesen |
whoami und context current enden mit 0, auch wenn nichts gespeichert ist: Sie berichten, was gesetzt ist, sie prüfen es nicht. Ein Skript unterscheidet die Fälle am Code:
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 ;;
esacFehlermeldungen gehen in die Standardfehlerausgabe, daher enthält incident.json nur die Antwort.
Antworten mit jq lesen
Schreiben Sie -o json in Skripten. In einer Pipe gibt die CLI ohnehin JSON aus, aber das Flag hält das Skript lauffähig, wo immer es läuft:
# 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'Eine Zählung gibt eine Zahl aus, bereit zum Vergleichen:
OPEN=$(status200 incident count --query '{"currentIncidentState":{"isResolvedState":false}}')
echo "$OPEN incidents are open"Datensätze aus Dateien erstellen
Bewahren Sie Datensätze als JSON-Dateien neben Ihrem Code auf und erstellen Sie sie von dort:
{
"name": "Checkout API",
"monitorType": "Manual"
}status200 monitor create --file monitors/checkout-api.jsonViele Datensätze aus einem JSON-Array, ein Erstellen für jeden:
jq -c '.[]' monitors.json | while IFS= read -r monitor; do
status200 monitor create --data "$monitor" -o json | jq -r '._id'
doneJeder Lauf erstellt neue Datensätze. Um Monitore und Statusseiten mit Dateien im Gleichschritt zu halten, nur das Geänderte zu ändern und das Entfernte zu entfernen, verwenden Sie den Terraform-Provider.
Beispiele für Pipelines
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 fügen Sie STATUS200_API_KEY unter Settings → Secrets and variables → Actions des Repositorys hinzu; in GitLab als maskierte CI/CD-Variable. Mit dem Docker-Image übergeben Sie die Variablen jedem Lauf:
docker build -t status200-cli .
docker run --rm -e STATUS200_API_KEY -e STATUS200_URL status200-cli incident count