API-Keys sind die Bearer-Tokens mit denen deine CI und der GitHub-Action-Wrapper gegen das Portal authentifizieren. Jeder Key gehört zu einem User, gilt unabhängig vom Login-Cookie und kann unabhängig revoct werden.
Key erzeugen
Auf /api-keys:
- Name vergeben, frei wählbar. Empfehlung: was der Key tut bzw.
wo er liegt, z.B.
acme-web-ci. Du siehst den Namen später in der Übersicht und beim Audit. - Lifetime wählen. 30 Tage, 90 Tage, 1 Jahr oder unbegrenzt. Kurze Lifetimes sind sicherer, brauchen aber häufigeren Austausch.
- Create klicken.
Den Klartext-Wert kopieren
Direkt nach der Erzeugung zeigt das Portal einmal den vollen Klartext des Keys. Kopier ihn sofort, wir speichern nur einen Hash, der Klartext ist nach dem Schließen der Box weg.
Wenn du den Wert vergessen hast: einfach neuen Key erzeugen, alten revoken. Wir können dir den Wert nachträglich nicht zeigen.
Key in deiner CI hinterlegen
Den kopierten Wert als Secret in deinem CI-System speichern. Details pro CI-System unter API-Keys in Secrets.
GitHub Actions Schnellanleitung:
Repo → Settings → Secrets and variables → Actions → New repository secret
Name: CODECHARTER_API_KEY
Value: <der Klartext-Wert>
Im Workflow:
- uses: bochmann-software/codeguard@v1
with:
api-key: ${{ secrets.CODECHARTER_API_KEY }}
Key revoken
Im Portal in der API-Key-Liste neben dem Eintrag "Revoke" klicken. Ab dem nächsten CI-Aufruf bekommt der Key 401 Unauthorized.
Es gibt keinen "Un-Revoke", wenn du dich versehentlich vertippt hast, einfach neuen Key erzeugen.
Key austauschen
Wenn ein Key kompromittiert ist oder ein Team-Mitglied geht, das den Klartext gesehen haben könnte, ersetzt du ihn so:
- Neuen Key erzeugen im Portal.
- Im CI-System den neuen Wert in dieselbe Secret-Variable
(
CODECHARTER_API_KEY) schreiben. - Alten Key revoken.
Ein Overlap-Zeitfenster für unterbrechungsfreies Umstellen gibt es nicht — vor dem Revoke kurz prüfen, dass das CI-System den neuen Wert geladen hat, und Builds zwischen Schritt 2 und 3 pausieren falls möglich.
Mehrere Keys dürfen gleichzeitig aktiv sein; du kannst also problemlos einen zweiten Key vorhalten, etwa für ein paralleles CI-System.
Was ein Key kann
Ein Key autorisiert den Lese-Zugriff auf alle Release-Assets, die zu deiner Subscription gehören. Damit pullen CI-Workflows Installer, CLI-Binaries pro Plattform und die VSIX.
Was passiert beim Trial-Ende
Wenn deine Subscription expired ist, geben alle Keys ab dem nächsten Aufruf 403 zurück. Der Key bleibt aktiv aber unbrauchbar. Sobald die Subscription wieder läuft, funktioniert der Key wieder ohne Änderung.
Audit
In der API-Keys-Liste siehst du pro Key:
- Wann erzeugt
- Wann zuletzt benutzt
- Wie viele Pulls in den letzten 30 Tagen
- Aktueller Status (aktiv / revoked / expired)
Wenn ein Key auffällig viel oder gar nicht benutzt wird, ist das ein Signal: entweder ihn revoken weil unbenutzt, oder genauer hinschauen warum so viele Pulls.
Mehrere Keys parallel
Sinnvoll wenn du unterschiedliche CI-Setups hast, z.B. einen Key für das Haupt-CI und einen separaten für einen Build-Server in einer isolierten Umgebung. So kannst du einen revoken ohne den anderen zu treffen.
Es gibt heute kein hartes Limit für Keys pro Account, aber wir behalten uns vor das einzuführen wenn jemand Schindluder treibt.