Ir al contenido

CI para tus repositorios de GitHub
en servidores que gestionamos nosotros.

Cada push y pull request ejecuta tus tests en un sandbox sobre hardware de Enzonic que ya está en marcha cuando llega el job, con logs en directo y un check en GitHub. Escribe un .enzonic/ci.yml corto o mantén los flujos de trabajo de GitHub Actions que ya tienes.

3000 minutos al mes gratis. Sin tarjeta.

Ver una configuración
$ git push origin maina41c9e2Ejecución #128 aprobada en 2m 18slint22stest (node 20)1m 08stest (node 22)1m 21sdeploy26spostgres:17 · healthyTodos los checks han pasado4 jobs · Enzonic CI
Minutos de CI al mes
jobs a la vez
por job
de caché de dependencias

Todo lo que necesita un pipeline, sin nada que vigilar

Runners, servicios, cachés y logs forman parte del producto. Tú escribes los pasos.

Sandboxes que ya están en marcha

Cada job recibe su propio sandbox en hardware que opera Enzonic, arrancado por adelantado y descongelado cuando llega el job.

Jobs de matrix y needs

Prueba en Node 20 y 22 a la vez, y luego haz deploy solo cuando todas las celdas hayan pasado. Los jobs esperan a los jobs que necesitan.

Servicios Postgres y Valkey

Inicia una base de datos real junto a tus tests con una sola línea, con comprobación de estado antes del primer paso.

Cachés

Conserva node_modules, wheels de pip o la salida de build entre ejecuciones con una clave generada a partir de tu lockfile.

Artefactos

Conserva informes de cobertura, builds y capturas de pantalla, pásalos a los jobs posteriores y descárgalos durante días.

Logs en directo

Sigue cada paso mientras se ejecuta, con colores, agrupado por paso, y los pasos con errores se abren por ti.

Checks en GitHub

Cada job informa de un check con anotaciones en el pull request, listo para la protección de ramas.

Tus flujos de trabajo, sin cambios

Gran parte de los flujos de trabajo de GitHub Actions se ejecuta tal cual: matrix, services, containers y las acciones de configuración habituales.

Programaciones

Tests nocturnos o revisiones semanales de dependencias con una línea cron, en UTC.

Enzica arregla las ejecuciones fallidas

Un clic en un job fallido: Enzica encuentra la causa, hace push de una rama de arreglo y ejecuta el pipeline sobre ella.

Se acabó la espera, así que la ejecución son tus pasos

La mayor parte del tiempo de CI se va en arrancar una máquina, clonar y descargar dependencias. Enzonic CI hace ese trabajo antes de que llegue tu job.

  1. 01

    Sandboxes descongeladas, no arrancadas

    Un conjunto de sandboxes se arranca por adelantado. Cuando llega un job, se descongela una y se le entrega, así que no hay ninguna máquina que iniciar.

  2. 02

    Checkouts desde una réplica local

    Cada runner mantiene una réplica de tu repositorio y solo descarga lo que ha cambiado, en lugar de clonar desde GitHub en cada job.

  3. 03

    Cachés enlazadas desde el disco local

    Las cachés de dependencias se quedan en el runner y se enlazan al job, en lugar de descargarse y descomprimirse primero.

Cada job muestra en qué se fue su tiempo: cola, sandbox, checkout, dependencias, services, caché y pasos.

Un solo archivo en tu repositorio

Haz commit de .enzonic/ci.yml y haz push. Los jobs se ejecutan en el orden que marcan sus needs, las celdas de matrix en paralelo, cada una con sus propios services, caché y artefactos.

  • lint se ejecuta primero; ambas celdas de test empiezan cuando pasa
  • cada celda de test tiene su propio Postgres en localhost y como postgres:5432
  • las descargas de npm vienen de la caché indexada por package-lock.json
  • la cobertura se conserva aunque fallen los tests
  • el deploy solo se ejecuta en main, con un secreto que los logs nunca muestran
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  lint:
    image: node:22
    steps:
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint
    image: node:${{ matrix.node }}
    matrix:
      node: [20, 22]
    services:
      postgres:
        image: postgres:17-alpine
        env: { POSTGRES_PASSWORD: postgres }
    env:
      DATABASE_URL: postgres://postgres:postgres@postgres:5432/postgres
    cache:
      key: npm-${{ hashFiles('package-lock.json') }}
      paths: [~/.npm]
    steps:
      - run: npm ci
      - run: npm test
    artifacts:
      - name: coverage-node${{ matrix.node }}
        paths: [coverage/]
        when: always

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    steps:
      - run: npx enzonic deploy --prod
        env:
          ENZONIC_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

¿Ya usas GitHub Actions?

Conecta el repositorio y tus .github/workflows se ejecutan aquí sin cambios, siempre que usen lo que aparece abajo. Lo demás se rechaza con un mensaje claro, nunca se omite en silencio.

Se ejecuta tal cual

  • actions/checkoutSiempre se hace checkout del commit de la ejecución
  • actions/setup-node, setup-python, setup-go, setup-javaElige la imagen del job; cache: añade la caché del gestor de paquetes
  • oven-sh/setup-bun, pnpm/action-setupImagen de Bun, con pnpm instalado
  • actions/cache (and /restore, /save)Una caché de job, restaurada al principio y guardada al final
  • actions/upload-artifact, download-artifactArtefactos conservados con la ejecución y pasados entre jobs
  • strategy.matrix, needs, if, services, containerIncluidos include / exclude y fail-fast

No compatible

  • Otros usos: actions, actions de Docker, actions compuestas y flujos de trabajo reutilizables
  • Salidas de pasos y jobs (steps.*.outputs, needs.*.outputs)
  • Runners de Windows y macOS
  • pull_request_target
La lista completa de compatibilidad

Precios

CI viene incluido con tu plan de Enzonic Cloud, el mismo que cubre Deploy y Databases. Empieza con el plan Free; cambia a un plan superior cuando necesites más minutos o runners más grandes. Solo runners de Linux.

Planes de Enzonic CI
Todos los planes de Cloud incluyen CI
Free
0 US$
Starter
5 US$ / mes
4,17 US$ al mes, facturado anualmente
Recomendado
Pro
10 US$ / mes
8,33 US$ al mes, facturado anualmente
Growth
19 US$ / mes
15,83 US$ al mes, facturado anualmente
Business
29 US$ / mes
24,17 US$ al mes, facturado anualmente
Minutos de CI al mes30005000600015.00060.000
Jobs a la vez2461020
Job más largo360 min360 min360 min480 min720 min
Caché de dependencias2 GB5 GB10 GB20 GB50 GB
Artefactos conservados90 días90 días90 días180 días400 días
Logs conservados14 días30 días30 días60 días90 días

Subvenciones para creadores

¿Creas código abierto, estudias, enseñas o diriges una organización sin ánimo de lucro? Solicita tiempo gratis de Pro o Business y crédito de Cloud para Deploy y Databases.

  • Plan Pro o Business de hasta un año, para Deploy y Databases a la vez
  • Crédito de Cloud añadido a tu saldo
  • Para tu cuenta personal o todo tu equipo
  • Lo lee una persona y suele responderse en pocos días
  • Código abierto
  • Estudiantes
  • Sin ánimo de lucro
  • Startups
  • Educadores
  • Hackathons

Preguntas

¿Qué cuenta como minuto de CI?

Cada minuto iniciado de un job se redondea hacia arriba por job. Un minuto en un runner medio cuenta el doble y en uno grande cuatro veces. El tiempo en cola no cuenta, y los jobs que una nueva ejecución conserva del intento anterior no tienen coste.

¿Dónde se ejecutan los jobs?

En servidores que Enzonic gestiona por sí mismo, los mismos que dan soporte a Enzonic Deploy y Databases. Cada job tiene su propio sandbox gVisor con su propio sistema de archivos y red, y sus contenedores de servicio están junto a él. Los jobs nunca comparten el kernel de una máquina con el código de otro cliente.

¿Por qué los jobs empiezan tan rápido?

Los sandboxes se arrancan por adelantado y se descongelan cuando llega un job, en lugar de iniciar una máquina para cada job. El checkout viene de una réplica local de tu repositorio, y las cachés de dependencias se enlazan desde el disco local en lugar de descargarse. La mayor parte de una ejecución son tus propios pasos.

¿Qué sistemas operativos pueden usar los jobs?

Solo Linux. Los jobs se ejecutan en contenedores Linux; los runners de Windows y macOS no están disponibles.

¿Puedo mantener mis flujos de trabajo de GitHub Actions?

Sí, siempre que usen el subconjunto compatible: pasos run, matrix, needs, services, container, y las acciones checkout, setup-node, setup-python, setup-go, setup-java, setup-bun, pnpm, cache y artifact. Un flujo de trabajo que use cualquier otra cosa se omite con un mensaje claro, y los demás flujos siguen ejecutándose.

¿Qué pasa con los secretos y los pull requests desde forks?

Los secretos se cifran, solo llegan a los jobs que los usan y se ocultan en los logs. Los pull requests desde forks se ejecutan sin secretos, sin token de GitHub y sin guardar cachés, o no se ejecutan en absoluto si lo prefieres.

¿Cómo llegan los resultados a GitHub?

Como checks, con las líneas que fallan anotadas en el pull request, cuando la GitHub App tiene el permiso Checks. Sin él, como estados de commit. Las reglas de protección de rama pueden exigirlos como cualquier otro check.

¿Qué pasa si una ejecución falla?

Recibes un correo si lo quieres, y un botón Arreglar con Enzica en el job fallido. Enzica lee el log y tu configuración, hace push de un arreglo a una nueva rama enzica/ci-fix y ejecuta el pipeline sobre ella. Tus ramas nunca se modifican; tú fusionas el arreglo si es correcto.

¿Necesito alojar mi app en Enzonic?

No. CI funciona con cualquier repositorio de GitHub. Haz deploy desde un job a donde alojes tu app, con un secreto para el token, o a Enzonic Deploy.

¿Qué imágenes puede usar un job?

Cualquier imagen de contenedor pública: node, python, golang, eclipse-temurin, oven/bun o la tuya. Los servicios como postgres:17 y valkey/valkey:8 arrancan antes de los pasos y se puede acceder a ellos en localhost y por su nombre de servicio.

Tu próximo push puede ejecutarse aquí.

Envía también el resultado: Enzonic Deploy aloja apps web gratis.