La caja de CI de tu espacio

Tu espacio tiene computadoras propias para el CI de sus repos. Cada job corre en una caja nueva que se borra al terminar: no hereda nada del job anterior y tus secretos no se quedan en ella.

Cómo pedirla

En el workflow, cambia ubuntu-latest por la etiqueta de tu espacio:

jobs:  test:    runs-on: [self-hosted, ws-<tu-espacio>]

«Preparar repo» ya arma el CI con esa etiqueta. Los jobs que se quedan en ubuntu-latest siguen corriendo en GitHub, con sus minutos.

Qué trae

Está pensada para que un workflow escrito para ubuntu-latest corra sin cambios:

• Ubuntu 24.04 con sudo sin contraseña: sudo apt-get install … funciona.
• Docker con Buildx y Compose: services: (Postgres, Redis, MySQL…), container:, docker build y docker compose up.
• Node 22 con pnpm y yarn (corepack), Python 3, compilador de C/C++ y mise para otras versiones. actions/setup-node, setup-python y compañía funcionan como en GitHub.
• Playwright con sus dependencias del sistema y Chromium.
• Postgres, Redis, MySQL y SQLite instalados y apagados: sudo systemctl start postgresql si prefieres no usar services:.
• 4 vCPU, 4 GB de RAM y 24 GB de disco.

Caché y descargas

Sin configurar nada:

• actions/cache, el cache: de setup-node y setup-python, y cache-to: type=gha de Buildx guardan en una caché junto a la caja, no en GitHub. Cada repo y cada rama ven sólo lo suyo, con las mismas reglas que la caché de GitHub.
• Las imágenes de Docker Hub (postgres:16, node:22…) bajan de un espejo local.

La caja grande: 8g

Cuando un job junta Docker, una base y navegadores, 4 GB pueden no alcanzar. Agrega 8g:

    runs-on: [self-hosted, ws-<tu-espacio>, 8g]

Trae 8 vCPU y 8 GB, y ocupa dos lugares de CI de tu plan (si tu plan tiene uno, lo ocupa entero mientras corre).

Cuántos jobs a la vez

Tantos como lugares de CI tenga tu plan (F1: 1, F2: 2, F3: 3). Los demás esperan en la fila de GitHub y arrancan solos al liberarse un lugar.