Scripts de repo
Los scripts de repo son scripts de shell que configuras por repositorio
(Ajustes → Repositorios → el icono de terminal en la fila de un repo) y que
el servidor de Control Center ejecuta contra el worktree de un espacio de
ese repo: el checkout aislado en
<dataDir>/<workspaceId>/spaces/<spaceId>/repos/<repo>/ donde trabajan los
agentes.
Hay dos tipos:
| Script | Cuándo se ejecuta | Para qué sirve |
|---|---|---|
| Configuración | Justo después de aprovisionar un worktree para un espacio | Instalar dependencias, generar archivos, copiar .env |
| Archivado | Justo antes de destruir o recolectar un worktree | Limpiar recursos fuera del worktree (redes de Docker, túneles, estado externo) |
Dónde se ejecutan los scripts
Sección titulada «Dónde se ejecutan los scripts»Ambos scripts se ejecutan mediante bash -lc (un shell de inicio de sesión, así
que las herramientas instaladas con Homebrew/nvm están en el PATH) con el
worktree como directorio de trabajo y estas variables de entorno definidas:
| Variable | Valor |
|---|---|
CC_WORKSPACE_PATH |
El worktree (el cwd del script) |
CC_ROOT_PATH |
El repo de origen registrado: tu propio checkout |
CC_SPACE_ID |
El espacio al que pertenece el worktree |
CC_SPACE_NAME |
El nombre visible del espacio |
CC_REPO_NAME |
El nombre visible del repo |
Por ejemplo, un script de configuración que instala dependencias y trae el
.env del repo ignorado por git:
pnpm installcp "$CC_ROOT_PATH/.env" .envpnpm run buildComportamiento ante fallos
Sección titulada «Comportamiento ante fallos»- Un script de configuración que sale con un código distinto de cero (o supera su tiempo de espera de 5 minutos) hace fallar el aprovisionamiento del espacio: el espacio muestra el estado de fallo con un botón de reintento y se registra la cola de salida de la ejecución. Al reintentar se aprovisiona desde un worktree limpio y se vuelve a ejecutar el script: escribe los scripts de configuración de modo que una nueva ejecución tras una instalación parcial funcione (los gestores de paquetes ya se comportan así).
- Un script de archivado es de mejor esfuerzo: un fallo (o su tiempo de espera de 2 minutos) se registra, pero nunca bloquea la eliminación. El archivado se ejecuta en rutas de GC donde no hay nadie que pueda responder a una solicitud (espacio eliminado, PR fusionada, limpieza programada).
La configuración solo se ejecuta en un worktree nuevo: volver a despachar agentes a un espacio ya preparado reutiliza el checkout existente y no vuelve a pagar el coste de la instalación.
Historial de ejecuciones
Sección titulada «Historial de ejecuciones»Cada ejecución se registra con su estado, duración, código de salida y una cola
de salida acotada, visible en el mismo diálogo de ajustes, en “Ejecuciones
recientes” (la suscripción repos.watchScriptRuns la transmite en directo).
Permisos
Sección titulada «Permisos»Los scripts son shell que ejecuta el servidor, así que escribirlos está
restringido a los administradores del espacio de trabajo y protegido por la
clase de acción processSpawn, la misma red de barandillas que controla
cualquier otra operación que lance procesos.