Repositorios y CI/CD

Conectar repositorios y ejecutar pipelines en los eQuantic Runners.

Conectar repositorios#

Usa la GitHub App (recomendada) para permisos granulares gestionados por la organización, con tokens de instalación de corta duración. Azure DevOps ya está soportado: conecta una organización con un Personal Access Token y elige los repositorios (org/project/repo) — los webhooks (Service Hooks) se configuran automáticamente. GitLab también está disponible: conéctalo con un Personal Access Token — gitlab.com o tu propia instancia self-hosted — y elige los proyectos (subgrupos anidados en profundidad incluidos); los webhooks se configuran automáticamente. Bitbucket también es un proveedor de primera clase: conecta un workspace de Bitbucket con un app password o un token de API de Atlassian (con el e-mail de tu cuenta) y elige los repositorios (workspace/repo); los webhooks se configuran automáticamente. GitHub, GitLab, Bitbucket y Azure DevOps están todos soportados.

En pantallas grandes, la pantalla de Repositorios muestra los repositorios conectados de cada proveedor como tarjetas o como una lista compacta: cambia entre ambas vistas desde su barra de herramientas. Se abre tal como la dejaste, con la misma pestaña de proveedor, la misma vista y el mismo filtro de visibilidad, incluso después de cerrar el navegador. En el teléfono, la pantalla mantiene su propia presentación.

Pipelines#

La plataforma interpreta tus YAML de GitHub Actions, de Azure Pipelines (azure-pipelines.yml), de GitLab CI (.gitlab-ci.yml) y de Bitbucket Pipelines (bitbucket-pipelines.yml) y ejecuta los jobs en los eQuantic Runners. Funcionalidades:

• Grafo de jobs derivado de las dependencias needs:, con matrix builds que se expanden en nodos paralelos.
• Grupos de concurrencia exactamente como los ejecuta GitHub, para workflows y jobs (un espacio de nombres por repositorio): un run o job del grupo a la vez, cancel-in-progress, y queue — single deja esperando solo el más reciente, max hasta 100 atendidos por orden de llegada.
• Tasks reales de Azure Pipelines en los steps task:, resueltas desde tu propia organización (incluidas las tasks del marketplace); las tasks disponibles solo en PowerShell y las service connections aún no están soportadas.
• Logs en vivo por step, con re-run de todo / solo fallidos / job individual.
• Editor visual de steps (arrastrar y soltar) y modo de edición avanzada del YAML.
• Aprobación manual antes del despliegue a producción (quórum N-de-M) y environments protegidos.
• Caché configurable y secrets/variables por repositorio, con referencias a variables de servicios.
• Interruptores de pausa a dos niveles — desactiva un workflow ruidoso, o baja el interruptor maestro del repositorio para pausar todo su CI. Un pipeline en pausa deja de dispararse (pushes, ejecuciones programadas, dispatch manual) pero sigue listado con su historial; ambos interruptores vienen activados por defecto.

Workflows portables#

Un workflow escrito para GitHub se ejecuta aquí sin cambios. Hay algunas cosas que conviene saber:

• secrets.GITHUB_TOKEN viene dado, igual que en GitHub: es el token de instalación del repositorio conectado, y ${{ github.token }} devuelve el mismo valor. Nunca lo declaras — ninguno de tus secretos puede llamarse GITHUB_*.
• EQUANTIC_SPACE vale true en cada step. El resto del entorno imita al proveedor a propósito (GITHUB_ACTIONS=true, GITHUB_SERVER_URL=https://github.com) para que las actions reales se comporten igual que en GitHub — así que esta es la única variable que un workflow puede leer para saber dónde se ejecuta, para ese step raro que sí tiene que ser distinto.
• actions/cache funciona sobre nuestro propio servicio de caché, en las dos versiones del protocolo que la action conoce. cache-from: type=gha en un build de Docker usa el mismo almacén.
• Tu checkout está donde GitHub lo pone: $GITHUB_WORKSPACE es /home/runner/work/<repo>/<repo>, y su directorio padre es $RUNNER_WORKSPACE, que pertenece a tu job. Así un step escribe al lado del checkout como lo hacen los workflows — git clone … ../<repo>.wiki para leer la wiki de un repositorio, una salida de build fuera del árbol — y ${{ runner.workspace }} es ese padre, como en un runner alojado.
• Los tres tipos de action se ejecutan: JavaScript, composite y Docker. Una action Docker arranca como contenedor junto a tu job, con el workspace montado donde lo monta GitHub (/github/workspace): una imagen docker:// se descarga, y una action que trae Dockerfile se construye en el momento. Solo runs.pre-entrypoint y runs.post-entrypoint no se ejecutan, y el step lo dice en el log en lugar de saltárselos en silencio.
• shell: es la shell que pediste: bash, sh, python, pwsh o una plantilla propia como bash -e {0}. Un intérprete que la imagen no tiene falla el step nombrándolo, en vez de ejecutar tu script como otra cosa. defaults.run se aplica a nivel de workflow y de job, tanto para shell como para working-directory.
• github.event es el payload entregado, así que github.event.pull_request.number, github.event.head_commit.message y contains(github.event.pull_request.labels.*.name, …) se leen igual que en GitHub. github.event_name dice qué ocurrió de verdad, y los inputs de una ejecución manual llegan en inputs y en github.event.inputs.

Pull requests#

Con un repositorio conectado (GitHub, GitLab, Bitbucket o Azure DevOps), puedes optar por gestionar sus Pull Requests dentro de eQuantic en lugar de hacerlo en el proveedor — un opt-in por repositorio. El código permanece siempre en el proveedor; eQuantic nunca aloja el git.

• Opt-in en la pestaña Pull requests — activa los PRs gestionados por eQuantic, o sigue usando los PRs del proveedor (la opción predeterminada).
• Creación de PRs — elige el branch de origen → destino, título y descripción; cada PR recibe una numeración propia por repositorio.
• Lista con estados — open / draft / merged / closed, con filtros.
• Vista del diff — eQuantic calcula el diff por sí misma (three-dot, contra el merge-base, como en las UIs de los proveedores) y lo almacena: la pantalla de detalle muestra un resumen (archivos modificados, +adiciones −eliminaciones) y hunks unificados por archivo, con números de línea exactos. Los archivos binarios y los diffs muy grandes se marcan en lugar de renderizarse; los nuevos pushes al branch de origen actualizan el diff automáticamente mediante el webhook del repositorio.
• Revisión de código en el diff — comenta en cualquier línea del diff: los hilos quedan anclados a la línea exacta, con respuestas y resolución/reapertura. Cuando llegan nuevos commits, los hilos existentes nunca se pierden — se marcan como desactualizados y se agrupan por archivo.
• Comentarios bloqueantes — un comentario de revisión puede marcarse como bloqueante; los comentarios bloqueantes sin resolver se destacan en el PR (banner e indicador en la lista), y solo su autor puede resolverlos.
• Aprobaciones y conversación — los revisores aprueban o solicitan cambios (un veredicto vigente por revisor; el autor del PR no puede revisar su propio PR), con contadores de aprobaciones/cambios en el PR y en la lista — además de un feed de comentarios generales en el PR, junto a los hilos de línea.
• Protección de branch — en la configuración del repositorio, define reglas por patrón de branch (main, release/*): número mínimo de aprobaciones, historial lineal, exigir que el branch esté actualizado con el destino, descartar aprobaciones antiguas cuando llegan nuevos commits y si los comentarios bloqueantes sin resolver vetan el merge — además de las estrategias de merge permitidas y la predeterminada.
• Merge dentro de eQuantic — cuando se cumplen todas las condiciones (aprobaciones, ninguna solicitud de cambios, ningún comentario bloqueante sin resolver, reglas de protección), el PR puede fusionarse con merge commit, squash o rebase. eQuantic ejecuta el merge por sí misma y envía el resultado al proveedor mediante push — nunca a través de la API de merge del proveedor, nunca con force-push. Mientras el merge está bloqueado, el PR lista exactamente lo que falta; un PR también puede cerrarse sin merge.
• Cola de merge — en lugar de fusionar directamente, un PR puede entrar en la cola de merge de su branch de destino. La cola procesa las entradas en orden: cada una se prueba contra el estado actual del destino — un branch que se quedó atrás no necesita actualizarse a mano, y entrar en la cola está permitido aunque el branch esté desactualizado — y, si todas las condiciones se siguen cumpliendo en el momento del merge, eQuantic ejecuta el merge y hace push del resultado. Un conflicto o una condición sin cumplir retira la entrada de la cola con el motivo, y la siguiente avanza; las entradas en espera pueden salir de la cola, y el panel de la cola en la pestaña Pull requests muestra las posiciones y el estado en vivo.
• Checks de CI — las ejecuciones de pipeline sobre los commits del PR reportan su estado de forma nativa en el PR: un check por workflow, por commit — pendiente, éxito o fallo — visible en el panel de merge. Una regla de protección de branch puede además exigir checks: el PR solo se fusiona cuando todos los checks reportados han pasado — un check fallido o aún en ejecución bloquea el merge, igual que la ausencia de cualquier check reportado (un check exigido nunca pasa en silencio). La misma exigencia se aplica también a las entradas de la cola de merge.

Entornos de preview#

Cada Pull Request abierto puede tener un entorno de preview efímero — un servicio aislado, construido a partir del branch del PR, con su propia URL (pr-N.preview.<dominio-de-deploy>).

• Configuración por repositorio en la pestaña Previews: el toggle de auto-preview, el Space de destino y un entorno base opcional cuyas variables se clonan en cada preview.
• Ciclo de vida automático — PR abierto → entorno aprovisionado; nuevos pushes → redeploy; merge/cierre → teardown. La tarjeta muestra el estado en vivo (building → ready / failed), la URL, branch/commit y autor.
• Modo manual — la pestaña lista los PRs abiertos sin preview, con creación en un clic; los previews existentes se pueden reconstruir o destruir desde el menú de la tarjeta.
• La URL del preview se publica como comentario en el PR y se mantiene actualizada.