Vier Provider, ein Ablauf
GitHub, GitLab, Azure DevOps und Bitbucket. Gleicher Befehl, gleiche Konfiguration, egal wo dein Skills-Repo liegt.
Git-Provider
Deine Skills, wo dein Code schon lebt
Derselbe Ablauf, egal welcher Git-Host. STH spricht direkt mit den Provider-APIs — kein Proxy, kein Dritter zwischen dir und deinem Code.
$ sth init ? Provider › GitHub GitLab Azure DevOps Bitbucket STH Cloud # Aucun secret stocké : token résolu via $STH_TOKEN, OIDC ou git credential
Das kannst du tun
Keine gespeicherten Secrets
STH speichert keine Schlüssel. Tokens werden aus deinen Umgebungsvariablen gelesen, genau wie bei git oder gh.
Kaskadierende Credential-Kette
Inline-Token, STH-Cloud-Keychain, STH_TOKEN, GitHub-Actions-OIDC, providerspezifische Variablen, git credential fill, dann interaktive Eingabe — in dieser Reihenfolge.
Mehrere Provider parallel
Ein GitHub-PAT für Kunde A, ein GitLab-PAT für Kunde B: Jedes Projekt behält seine eigene Konfiguration.
Häufige Fragen
- Speichert STH meine Tokens?
- Nein. Anmeldedaten werden pro Anfrage aus Umgebung, Keychain oder git aufgelöst und nie in die Projektkonfiguration geschrieben.
- Welche Mindestberechtigung braucht das Token?
- Lesezugriff auf das Repository: Contents: Read (GitHub), read_repository (GitLab), Code (Read) (Azure DevOps) oder Repositories: Read (Bitbucket).
- Funktioniert STH in der CI?
- Ja. In der CI liest STH STH_TOKEN oder GitHub-Actions-OIDC, ganz ohne interaktive Eingabe.