kanman die Toolchain Ihres Teams geben

Legen Sie einmal fest, welches Image, welche Variablen, Secrets und welches Setup Ihre Repositories brauchen. kanmans Codearbeit und Sammeländerungen laufen darin, auf Ihren Runnern und in der kanman Cloud.

Ihre 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, beschreiben Sie sie einmal für das Team als dessen Umgebung. kanman arbeitet dann darin:

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

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

Die Umgebung einrichten

Öffnen Sie Team > Prüfungen und Auslieferung und suchen Sie Team-Umgebung. Owner und Admins können sie bearbeiten.

Feld Bedeutung
Basis-Image Das Container-Image mit Ihrer Toolchain, zum Beispiel golang:1.25, eclipse-temurin:21 oder python:3.12, oder ein Image aus Ihrer eigenen Registry, zum Beispiel registry.gitlab.example.com/platform/go-toolchain:1.25. Verwenden Sie ein Image auf Basis von Debian, Ubuntu oder Red Hat; Alpine-Images werden für den Coding-Agent 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 (die Secrets unter Was ich ändern darf in Team > Grenzen und Budgets), 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. Nennen Sie 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-Agents 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 Ihr Runner erreicht, auch Hosts hinter Ihrem VPN. Isoliertes Netzwerk gibt dem Container ein eigenes Netzwerk mit reinem Internetzugang.

Die Befehle selbst bleiben in Ihren Repositories: Der Coding-Agent führt die eigenen Build- und Testbefehle Ihres Repositorys, zum Beispiel make test, in der Umgebung aus.

Ein Beispiel für Go-Services, deren private Module aus Ihrem 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 Ihres Runners.

Ist Ihr GitLab über den Runner verbunden, brauchen Sie kein eigenes Lese-Token: Der Coding-Agent liest über Ihren Runner aus Ihrem GitLab, nur lesend, und kein Token gelangt in seine Umgebung.

Images aus Ihrer 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. Geben Sie Ihren 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ählen Sie Zugangsdaten hinzufügen.
  2. Geben Sie 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ählen Sie 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. Ändern Sie das Basis-Image und wählen Umgebung speichern in einem Workspace, der auf eigenen Runnern läuft, zieht einer Ihrer Runner das Image mit den Zugangsdaten des Teams und prüft, ob der Coding-Agent darin laufen kann. Sie sehen “… 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ählen Sie Ohne Prüfung speichern; der erste Lauf meldet dann dasselbe Problem, falls es eines gibt.

Status der Umgebung

Wählen Sie Umgebung speichern, um Ihre Änderungen zu behalten (eine Umgebung wird als Ganzes gespeichert; Abbrechen verwirft Ihre Änderungen). Unter Status der Umgebung sehen Sie:

  • 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 Ihren Runnern. Der Runner baut das Image des Teams einmal (Ihr Image plus kanmans kleine Schicht mit dem Coding-Agent) und verwendet es für jeden Lauf wieder. Für jeden Lauf startet er den Coding-Agent 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 der Agent braucht. Die eigenen Tokens des Runners, sein Home-Ordner und sein Docker-Zugang bleiben draußen. Ist der Agent fertig, pusht der Runner den Branch selbst, außerhalb des Containers. Ein Image aus Ihrer eigenen Registry wird mit den Zugangsdaten des Teams gezogen. Ihr Runner braucht nichts außer Docker; siehe Den Self-hosted Runner betreiben.

In der kanman Cloud. kanman baut das Image Ihres 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 Ihnen, 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 Ihrem 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