# Lockpick in CI ausführen

Prüfe deine Site mit einem Pulse-Scan, wenn du ein Release veröffentlichst, und lass den Build fehlschlagen, wenn offene schwerwiegende Befunde vorliegen.

Die CLI läuft in jeder CI, die Node.js 20.9 oder neuer hat. Ein Pulse-Scan in CI verbraucht bei jedem Lauf einen Pulse-Scan aus deinem Monatskontingent, genauso wie wenn du ihn in Lockpick startest. Starte ihn deshalb beim Veröffentlichen eines Releases und nicht bei jedem Push.

## Workflow schreiben

Aus deinem Repository heraus, mit angemeldeter CLI:

```bash title="Terminal"
lockpick ci init <site>
```

Der Befehl schreibt `.github/workflows/lockpick.yml`. Der Workflow läuft, wenn du ein Release veröffentlichst, und wenn du ihn im Actions-Tab startest. Er startet einen Pulse-Scan der Site, wartet auf das Ergebnis und schlägt fehl, wenn offene Befunde den Schweregrad `high` oder höher haben. Er fixiert die CLI-Version, mit der er geschrieben wurde.

* `--fail-on critical`, `high`, `medium` oder `low` legt die Grenze fest.
* `--dry-run` gibt den Workflow aus, ohne ihn zu schreiben.
* `--file <path>` schreibt ihn an einen anderen Ort, und `--force` ersetzt eine bestehende Datei.

Wenn die CLI bei einer lokalen Adresse angemeldet ist, warnt dich `ci init`. Die Runner von GitHub erreichen nur eine öffentliche Lockpick-Adresse. Übergib dann `--host` mit dieser Adresse.

## Schlüssel hinzufügen

Der Workflow liest seinen Schlüssel aus dem Repository-Secret `LOCKPICK_KEY`. Verwende einen Schlüssel, der Pulse-Scans starten darf.

```bash title="Terminal"
gh secret set LOCKPICK_KEY
```

> **Careful**
>
> Ein Schlüssel kann alles, was du bei der Anmeldung erlaubt hast. Bewahre ihn
> im Secret-Speicher deiner CI auf, niemals in deinem Repository, und widerrufe
> ihn in Lockpick unter **Zu deiner KI hinzufügen** auf dem Tab **CLI und
> Schlüssel**, wenn du ihn nicht mehr brauchst.

## Bei Befunden überall fehlschlagen

`--fail-on` funktioniert bei jedem Befehl, der mit einem fertigen Scan endet: `lockpick pulse`, `lockpick recheck`, `lockpick watch`, `lockpick deep start` und `lockpick findings`. `lockpick ci check <run-id>` wendet die Grenze auf einen bereits abgeschlossenen Scan an, ohne einen neuen zu starten und ohne dein Kontingent zu verbrauchen. Außerdem kann er bei seinem Alter (`--max-age-hours`) oder seiner Abdeckung (`--min-coverage`) fehlschlagen. Erreichen offene Befunde die Grenze, endet der Befehl mit Code 8, sodass jede CI den Build stoppen kann:

```bash title="Terminal"
lockpick pulse <site> --fail-on high --timeout 900
```

In CI gibt die CLI jedes Mal eine Zeile aus, wenn sich der Status eines Scans ändert, statt einer Live-Fortschrittsanzeige. Mit `--json` gibt sie nur das Ergebnis aus. Setze `FORCE_COLOR=1`, damit ein Log, das Farben anzeigt, auch Farben zeigt.

## CLI- und Exit-Codes des Release-Scan-Skripts

Die CLI und das eigenständige [Release-Scan-Skript](/de/docs/protect/release-scans) verwenden unterschiedliche Exit-Verträge. Prüfe, welches davon dein Job ausführt.

| Ergebnis                                 | `lockpick`-CLI                                          | Eigenständiges Release-Scan-Skript |
| ---------------------------------------- | ------------------------------------------------------- | ---------------------------------- |
| Innerhalb der Befundgrenze abgeschlossen | 0                                                       | 0                                  |
| Offene Befunde haben die Grenze erreicht | 8                                                       | 1                                  |
| Scan fehlgeschlagen oder anderer Fehler  | Siehe [CLI-Exit-Codes](/de/docs/cli/install#exit-codes) | 1                                  |

Das Release-Scan-Skript verwendet einen CI-Schlüssel, der auf eine Site beschränkt ist (`LOCKPICK_CI_KEY`). Die CLI verwendet `LOCKPICK_KEY` und die Berechtigungen, die du ihr erteilt hast.