Repo-Skripte

Repo-Skripte sind Shell-Skripte, die du je Repository einrichtest (Einstellungen → Repositorys → das Terminal-Symbol in der Zeile eines Repos) und die der Server von Control Center im Worktree eines Bereichs dieses Repos ausführt — dem isolierten Checkout unter <dataDir>/<workspaceId>/spaces/<spaceId>/repos/<repo>/, in dem Agenten arbeiten.

Es gibt zwei Arten:

Skript	Wann es läuft	Wofür du es nutzt
Setup	Direkt nachdem ein Worktree für einen Bereich bereitgestellt wurde	Abhängigkeiten installieren, Dateien erzeugen, .env kopieren
Archivierung	Kurz bevor ein Worktree zerstört oder von der Garbage Collection abgeräumt wird	Ressourcen außerhalb des Worktrees aufräumen (Docker-Netzwerke, Tunnel, externer Zustand)

Wo die Skripte laufen

Beide Skripte laufen über bash -lc (eine Login-Shell, damit über Homebrew oder nvm installierte Werkzeuge auf PATH liegen), mit dem Worktree als Arbeitsverzeichnis und diesen Umgebungsvariablen:

Variable	Wert
CC_WORKSPACE_PATH	Der Worktree (das Arbeitsverzeichnis des Skripts)
CC_ROOT_PATH	Das registrierte Quell-Repo — dein eigener Checkout
CC_SPACE_ID	Der Bereich, zu dem der Worktree gehört
CC_SPACE_NAME	Der Anzeigename des Bereichs
CC_REPO_NAME	Der Anzeigename des Repos

Zum Beispiel ein Setup-Skript, das Abhängigkeiten installiert und die von Git ignorierte .env des Repos hereinholt:

pnpm install
cp "$CC_ROOT_PATH/.env" .env
pnpm run build

Verhalten bei Fehlern

• Ein Setup-Skript, das mit einem Exit-Code ungleich null endet (oder sein Zeitlimit von 5 Minuten überschreitet), lässt die Bereitstellung des Bereichs scheitern: Der Bereich zeigt den fehlgeschlagenen Zustand mit einem erneuten Versuch, und das Ende der Ausgabe des Laufs wird festgehalten. Ein erneuter Versuch stellt aus einem sauberen Worktree bereit und führt das Skript noch einmal aus — schreibe Setup-Skripte so, dass ein erneuter Lauf nach einer unvollständigen Installation funktioniert (Paketmanager verhalten sich schon so).
• Ein Archivierungsskript läuft nach bestem Bemühen: Ein Fehler (oder sein Zeitlimit von 2 Minuten) wird festgehalten, blockiert das Löschen aber nie. Die Archivierung läuft auf GC-Pfaden, auf denen niemand eine Rückfrage beantworten kann (Bereich gelöscht, PR gemergt, geplantes Aufräumen).

Das Setup läuft nur auf einem frischen Worktree: Ein erneuter Dispatch von Agenten in einen warmen Bereich verwendet den bestehenden Checkout weiter, und die Installation fällt nicht noch einmal an.

Laufhistorie

Jede Ausführung wird mit Status, Dauer, Exit-Code und einem begrenzten Auszug vom Ende der Ausgabe festgehalten, sichtbar im selben Einstellungsdialog unter „Letzte Ausführungen“ (die Subscription repos.watchScriptRuns streamt sie live).

Berechtigungen

Die Skripte sind Shell, die der Server ausführt, deshalb ist das Schreiben Admins des Arbeitsbereichs vorbehalten und an die Aktionsklasse processSpawn gebunden — dasselbe Netz der Schutzregeln, das jede andere Operation passieren muss, die einen Prozess startet.