kanman die Toolchain deines Teams geben

Leg einmal fest, welches Image, welche Variablen, Secrets und welches Setup deine Repositories brauchen. kanmans Codearbeit und Sammeländerungen laufen darin, auf deinen Runnern und in der kanman Cloud.

Deine Repositories brauchen eine Toolchain: eine Go-Version, ein JDK, Python mit seinen Paketen, Zugangsdaten für private Module. Statt sie auf jedem Runner zu installieren, beschreibst du sie einmal für das Team als dessen Umgebung. kanman arbeitet dann darin:

  • das Coding-Werkzeug schreibt und testet Code darin,
  • Sammeländerungen über viele Repositories führen ihre Update-Befehle darin aus.

Alle verwenden dasselbe Image, auf deinen eigenen Runnern und in der kanman Cloud.

Die Umgebung einrichten

Öffne Team > Umgebung und dann die Zeile Image und Setup. Owner und Admins können sie bearbeiten.

Feld Bedeutung
Basis-Image Das Container-Image mit deiner Toolchain, zum Beispiel golang:1.25, eclipse-temurin:21 oder python:3.12, oder ein Image aus deiner eigenen Registry, zum Beispiel registry.gitlab.example.com/platform/go-toolchain:1.25. Verwende ein Image auf Basis von Debian, Ubuntu oder Red Hat; Alpine-Images werden für das Coding-Werkzeug nicht unterstützt.
Variablen Einfache Einstellungen, die jeder Befehl braucht, eine NAME=Wert pro Zeile, zum Beispiel GOPRIVATE=gitlab.example.com. Nicht für Secrets.
Mitgegebene Secrets Workspace-Secrets, die die Umgebung braucht, ausgewählt aus den Secrets, die dieses Team verwenden darf (Workspace-Secrets in Team > Umgebung), zum Beispiel ein Lese-Token für private Module. Ihre Werte erscheinen nie in Logs.
Caches zwischen Runs Ordner, die zwischen Läufen erhalten bleiben, damit Downloads nicht wiederholt werden, einer pro Zeile. Nenn den ganzen Ordner, in den ein Werkzeug schreibt, zum Beispiel /go/pkg für Go (seine Module und deren Prüfsummen), nicht einen Ordner darin. Ein Pfad, der mit ~/ beginnt, liegt im Home-Ordner der Umgebung.
Einrichtungsschritt Ein Shell-Befehl, der vor dem Start des Coding-Werkzeugs läuft, zum Beispiel eine git-Einstellung, die mit einem Secret private Module abruft. Er muss mehrfach ausführbar sein.
Netzwerk Host-Netzwerk erreicht alles, was dein Runner erreicht, auch Hosts hinter deinem VPN. Isoliertes Netzwerk gibt dem Container ein eigenes Netzwerk mit reinem Internetzugang.

Die Befehle selbst bleiben in deinen Repositories: Das Coding-Werkzeug führt die eigenen Build- und Testbefehle deines Repositorys, zum Beispiel make test, in der Umgebung aus.

Ein Beispiel für Go-Services, deren private Module aus deinem GitLab kommen, mit einem Lese-Token, das dem Team als Secret FM_GITLAB_READ_TOKEN freigegeben ist:

Feld Wert
Basis-Image golang:1.25
Variablen GOPRIVATE=gitlab.example.com und GONOSUMDB=gitlab.example.com
Mitgegebene Secrets FM_GITLAB_READ_TOKEN
Caches zwischen Runs /go/pkg und ~/.cache/go-build
Einrichtungsschritt git config --global url."https://oauth2:${FM_GITLAB_READ_TOKEN}@gitlab.example.com/".insteadOf https://gitlab.example.com/
Netzwerk Host-Netzwerk

Die Zugangsdaten liegen nur in der Umgebung, nie in der git-Konfiguration deines Runners.

Ist dein GitLab über den Runner verbunden, brauchst du kein eigenes Lese-Token: Das Coding-Werkzeug liest über deinen Runner aus deinem GitLab, nur lesend, und kein Token gelangt in seine Umgebung.

Images aus deiner eigenen Registry

Ein Team kann ein ganz eigenes Image aus jeder Registry mitbringen: der Container-Registry von GitLab, Harbor, der GitHub Container Registry, einem privaten Docker-Hub-Repository oder jeder anderen OCI-Registry. Gib deinen Runnern unter Zugangsdaten für Registries, unter dem Status der Umgebung, Lesezugriff (Owner und Admins, in Workspaces, deren Arbeit auf eigenen Runnern läuft):

  1. Wähle Zugangsdaten hinzufügen.
  2. Gib den Host der Registry ein, zum Beispiel registry.gitlab.example.com oder harbor.example.com:8443, einen Benutzernamen und ein Passwort oder Token. Ein Token mit Lesezugriff auf die Registry genügt: ein GitLab-Deploy-Token mit read_registry, ein Harbor-Robot-Account, ein GitHub-Token mit read:packages.
  3. Wähle Speichern. Das Passwort wird nie wieder angezeigt; die Liste zeigt die Registry, wer sie gesetzt hat und wann.

Der Runner nutzt diese Zugangsdaten nur, um das Image dieses Teams zu ziehen: Jeder Pull bekommt eine eigene Docker-Konfiguration, die direkt danach gelöscht wird, nie den eigenen Docker-Login des Runners, und kein anderes Team kann sie nutzen. Ein Image, das ein Runner mit den Zugangsdaten eines Teams gezogen hat, bleibt bei diesem Team: Ein anderes Team startet es nur mit eigenem Zugang. Die kanman Cloud baut Team-Images nur aus Images, die sie ohne Zugangsdaten ziehen kann.

Das Image wird vor dem Speichern geprüft. Änderst du das Basis-Image und wählst Umgebung speichern in einem Workspace, der auf eigenen Runnern läuft, zieht einer deiner Runner das Image mit den Zugangsdaten des Teams und prüft, ob das Coding-Werkzeug darin laufen kann. Du siehst “… wird auf deinem Runner geprüft”, dann die gefundenen Werkzeuge (“Auf deinem Runner geprüft: go go1.25.1”), und die Umgebung ist gespeichert. Schlägt die Prüfung fehl, bleibt die Umgebung ungespeichert, und der Grund sagt, was zu tun ist:

Meldung Was zu tun ist
Der Runner darf dieses Image nicht ziehen Zugangsdaten für die Registry des Images ergänzen oder korrigieren.
Das Image gibt es nicht Name und Tag prüfen.
Der Runner erreicht die Registry nicht Netzwerk und Proxy des Runners prüfen.
Das Image hat kein /bin/sh Ein Image mit Shell verwenden.
Das Image basiert auf Alpine (musl) Ein Image auf Basis von Debian, Ubuntu oder Red Hat verwenden.

Ist kein Runner online, um das Image zu prüfen, wähle Ohne Prüfung speichern; der erste Lauf meldet dann dasselbe Problem, falls es eines gibt.

Status der Umgebung

Wähle Umgebung speichern, um deine Änderungen zu behalten (eine Umgebung wird als Ganzes gespeichert; Abbrechen verwirft deine Änderungen). Unter Status der Umgebung siehst du:

  • die Version der Umgebung, die sich bei jeder Änderung eines Feldes ändert,
  • die gefundenen Werkzeuge im Image mit ihren Versionen, zum Beispiel go1.25.1,
  • das Image in kanman Cloud mit Status und Zeit seines letzten Builds.

Wo sie läuft

Auf deinen Runnern. Der Runner baut das Image des Teams einmal (dein Image plus kanmans kleine Schicht mit dem Coding-Werkzeug) und verwendet es für jeden Lauf wieder. Für jeden Lauf startet er das Coding-Werkzeug in einem Container dieses Images, mit dem eingebundenen Checkout des Repositories. In den Container gehen nur die Variablen der Umgebung, ihre Secrets und die eine Modell-Zugangsberechtigung, die das Coding-Werkzeug braucht. Die eigenen Tokens des Runners, sein Home-Ordner und sein Docker-Zugang bleiben draußen. Ist das Coding-Werkzeug fertig, pusht der Runner den Branch selbst, außerhalb des Containers. Ein Image aus deiner eigenen Registry wird mit den Zugangsdaten des Teams gezogen. Dein Runner braucht nichts außer Docker; siehe Den Self-hosted Runner betreiben.

In der kanman Cloud. kanman baut das Image deines Teams einmal pro Version der Umgebung. Der erste Lauf nach einer Änderung wartet auf den Build, meist ein bis zwei Minuten; der Lauf zeigt, dass er wartet. Spätere Läufe starten sofort aus dem gebauten Image. Schlägt der Build fehl, stoppt der Lauf mit dem Grund, zum Beispiel einem Image-Namen, den es nicht gibt, und die Team-Seite sagt dir, was zu korrigieren ist.

Teams ohne Umgebung arbeiten wie bisher.

Sehen, welche Umgebung ein Lauf verwendet hat

Die Lauf-Seite zeigt die Umgebung jedes Versuchs: das Image, die wichtigste Tool-Version und ob er in einem Container auf deinem Runner oder aus dem Team-Image in der kanman Cloud lief.

Repositories mit eigener Konfiguration

Jedes Repository des Teams nutzt die Team-Umgebung. Ein Repository, das eine andere Toolchain braucht, gehört in ein Team mit dieser Umgebung.

Zuletzt aktualisiert: January 1, 0001

kanman öffnen