Quatre providers, un seul flux
GitHub, GitLab, Azure DevOps et Bitbucket. Même commande, même configuration, où que vive votre dépôt de skills.
Providers Git
Vos skills, là où vit déjà votre code
Le même flux, quel que soit votre hébergeur Git. STH dialogue directement avec les API des providers — aucun proxy, aucun service tiers entre vous et votre code.
$ sth init ? Provider › GitHub GitLab Azure DevOps Bitbucket STH Cloud # Aucun secret stocké : token résolu via $STH_TOKEN, OIDC ou git credential
Ce que vous pouvez faire
Zéro secret stocké
STH ne persiste aucune clé. Les tokens sont lus depuis vos variables d'environnement, comme le feraient git ou gh.
Chaîne de résolution en cascade
Token inline, keychain STH Cloud, STH_TOKEN, OIDC GitHub Actions, variables spécifiques au provider, git credential fill, puis invite interactive — dans cet ordre.
Plusieurs providers en parallèle
Un PAT GitHub pour le client A, un PAT GitLab pour le client B : chaque projet garde sa propre configuration.
Questions fréquentes
- STH stocke-t-il mes tokens ?
- Non. Les identifiants sont résolus à chaque requête depuis l'environnement, le keychain ou git, et ne sont jamais écrits dans la configuration du projet.
- Quelle permission minimale donner au token ?
- Un accès lecture au dépôt : Contents: Read (GitHub), read_repository (GitLab), Code (Read) (Azure DevOps) ou Repositories: Read (Bitbucket).
- STH fonctionne-t-il en CI ?
- Oui. En CI, STH lit STH_TOKEN ou l'OIDC GitHub Actions, sans aucune invite interactive.