# 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.

:::cards
- [Donner sa clé API à un script](#donner-sa-clé-api-à-un-script): Deux variables d'environnement, aucun contexte enregistré.
- [Codes de sortie](#codes-de-sortie): 0 quand cela a fonctionné, et pourquoi sinon.
- [Lire les réponses avec jq](#lire-les-réponses-avec-jq): Des ID, des titres et des dates tirés du JSON.
- [Exemples de pipelines](#exemples-de-pipelines): 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 :

```mermaid title="Un déploiement qui attend tant qu'un incident est ouvert"
flowchart TB
    J["La tâche de CI démarre"] --> S["Ses secrets définissent<br/>STATUS200_API_KEY<br/>et STATUS200_URL"]
    S --> Q["status200 incident count<br/>des incidents non résolus"]
    Q -->|"0"| D["Déployer"]
    Q -->|"1 ou plus"| X["Arrêt :<br/>un incident<br/>est ouvert"]
    Q -->|"code de<br/>sortie 2"| A["Arrêt :<br/>vérifier<br/>la clé API"]
```

## 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.

```bash
export STATUS200_API_KEY="$CI_STATUS200_API_KEY"
export STATUS200_URL="https://status200.ru"
status200 incident count
```

> [!TIP]
> Donnez à 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 :

```bash
status200 --context production incident count
status200 --context staging monitor count
```

## Codes 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 :

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

Les 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 :

```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 comptage affiche un seul nombre, prêt à être comparé :

```bash
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à :

```json title="monitors/checkout-api.json"
{
  "name": "Checkout API",
  "monitorType": "Manual"
}
```

```bash
status200 monitor create --file monitors/checkout-api.json
```

De nombreux enregistrements à partir d'un tableau JSON, une création chacun :

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

> [!NOTE]
> Chaque 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](/docs/terraform/index).

## Exemples de pipelines

:::tabs
@tab GitHub Actions
```yaml title=".github/workflows/deploy.yml"
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
```
@tab GitLab CI
```yaml title=".gitlab-ci.yml"
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
```
@tab Docker
```dockerfile title="Dockerfile"
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 :

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

## Étapes suivantes

:::cards
- [Authentification](/docs/cli/authentication): La clé qu'une commande utilise quand plusieurs sont définies.
- [Formats de sortie](/docs/cli/output-formats): Le JSON que vos scripts lisent.
- [Opérations sur les ressources](/docs/cli/resource-operations): Les filtres, la pagination et les champs d'un enregistrement.
- [Fournisseur Terraform](/docs/terraform/index): Garder la configuration de Status200 dans des fichiers.
:::