Scripts et CI/CD
La CLI fonctionne dans un script comme dans un terminal. Donnez-lui une clé API dans des variables d'environnement, lisez ses réponses en JSON, et laissez son code de sortie dire au script ce qui s'est passé. Cette page montre chacun de ces points, et des pipelines complets pour GitHub Actions, GitLab CI et Docker.
Comment un script utilise la CLI
Un déploiement peut d'abord demander à Status200 si un incident est ouvert, et s'arrêter s'il y en a un :
Un déploiement qui attend tant qu'un incident est ouvert
Donner sa clé API à un script
Définissez STATUS200_API_KEY et STATUS200_URL à partir des secrets de votre système de CI. La CLI n'a alors besoin ni de login ni de fichier de configuration. Une option passe toujours avant elles pour une seule commande, et elles passent avant les contextes enregistrés.
export STATUS200_API_KEY="$CI_STATUS200_API_KEY"
export STATUS200_URL="https://status200.ru"
status200 incident countDonnez à chaque pipeline sa propre clé API, avec seulement l'accès dont il a besoin : une vérification qui ne fait que lire a besoin d'une clé qui ne fait que lire. Supprimez la clé dans Status200 quand le pipeline est retiré.
Si une machine exécute des tâches pour plusieurs projets, enregistrez un contexte pour chacun et nommez-le dans chaque commande, afin qu'une tâche n'utilise jamais le contexte actuel d'une autre :
status200 --context production incident count
status200 --context staging monitor countCodes de sortie
| Code | Signification | Par exemple |
|---|---|---|
0 | Cela a fonctionné | Une liste, même une qui ne trouve rien |
1 | Cela a échoué | Status200 a refusé la requête, comme API error (422) ; du JSON non valide ; une option manquante ou inconnue ; un contexte qui n'est pas enregistré |
2 | Aucune clé API utilisable | Aucun identifiant trouvé ; une clé API non valide ; une clé sous son offre (402) ; 401 |
3 | Introuvable | Status200 a répondu 404 : l'enregistrement n'existe pas, se trouve dans un autre projet, ou la clé ne peut pas le lire |
whoami et context current se terminent avec 0 même quand rien n'est enregistré : ils indiquent ce qui est défini, ils ne le vérifient pas. Un script distingue les cas grâce au 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 ;;
esacLes messages d'erreur vont sur la sortie d'erreur standard : incident.json ne contient donc que la réponse.
Lire les réponses avec jq
Écrivez -o json dans les scripts. Dans un pipe, la CLI affiche de toute façon du JSON, mais l'option garde le script fonctionnel où qu'il tourne :
# 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 comptage affiche un seul nombre, prêt à être comparé :
OPEN=$(status200 incident count --query '{"currentIncidentState":{"isResolvedState":false}}')
echo "$OPEN incidents are open"Créer des enregistrements à partir de fichiers
Gardez les enregistrements sous forme de fichiers JSON à côté de votre code, et créez-les à partir de là :
{
"name": "Checkout API",
"monitorType": "Manual"
}status200 monitor create --file monitors/checkout-api.jsonDe nombreux enregistrements à partir d'un tableau JSON, une création chacun :
jq -c '.[]' monitors.json | while IFS= read -r monitor; do
status200 monitor create --data "$monitor" -o json | jq -r '._id'
doneChaque exécution crée de nouveaux enregistrements. Pour garder les moniteurs et les pages de statut alignés sur des fichiers, ne modifier que ce qui a changé et retirer ce qui a disparu, utilisez le fournisseur Terraform.
Exemples de 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"]Dans GitHub Actions, ajoutez STATUS200_API_KEY sous Settings → Secrets and variables → Actions du dépôt ; dans GitLab, ajoutez-la comme variable CI/CD masquée. Avec l'image Docker, passez les variables à chaque exécution :
docker build -t status200-cli .
docker run --rm -e STATUS200_API_KEY -e STATUS200_URL status200-cli incident count