Fire leverandører, én flyt
GitHub, GitLab, Azure DevOps og Bitbucket. Samme kommando, samme konfigurasjon, uansett hvor ferdighets-repoet ditt ligger.
Git-leverandører
Ferdighetene dine, der koden din allerede bor
Samme flyt uansett Git-vert. STH snakker direkte med leverandørenes API-er — ingen proxy, ingen tredjepart mellom deg og koden din.
$ sth init ? Provider › GitHub GitLab Azure DevOps Bitbucket STH Cloud # Aucun secret stocké : token résolu via $STH_TOKEN, OIDC ou git credential
Dette kan du gjøre
Ingen lagrede hemmeligheter
STH lagrer ingen nøkler. Token leses fra miljøvariablene dine, akkurat som git eller gh gjør.
Kaskaderende legitimasjonskjede
Inline-token, STH Cloud-nøkkelring, STH_TOKEN, GitHub Actions-OIDC, leverandørspesifikke variabler, git credential fill, så interaktiv forespørsel — i den rekkefølgen.
Flere leverandører parallelt
En GitHub-PAT for kunde A, en GitLab-PAT for kunde B: hvert prosjekt beholder sin egen konfigurasjon.
Vanlige spørsmål
- Lagrer STH tokenene mine?
- Nei. Legitimasjon løses per forespørsel fra miljøet, nøkkelringen eller git, og skrives aldri til prosjektkonfigurasjonen.
- Hva er minste tillatelse for tokenet?
- Lesetilgang til repoet: Contents: Read (GitHub), read_repository (GitLab), Code (Read) (Azure DevOps) eller Repositories: Read (Bitbucket).
- Fungerer STH i CI?
- Ja. I CI leser STH STH_TOKEN eller GitHub Actions-OIDC, helt uten interaktiv forespørsel.