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.

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.
• 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.

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.