// Documentación de Singularity
Pipelines: seguir la CI y preparar una corrección
El plugin Pipelines reúne en Singularity las ejecuciones CI/CD de tus proyectos: lista de pipelines, pasos, registros, relanzamientos y, cuando una ejecución falla, un ticket de reparación con IA en un clic.
Activar y conectar el plugin
Instala y activa Pipelines desde el Marketplace. Este plugin de pago es compatible con GitHub Actions, GitLab CI y Azure DevOps. Añade una conexión en sus ajustes: nombre, proveedor, URL de la organización, proyecto y token, y luego Test and add.
Las conexiones están vinculadas al espacio de trabajo y los tokens se guardan aparte, en el llavero aislado del plugin: nunca se devuelven a la interfaz. Si no aparece ninguna definición, comprueba el espacio de trabajo activo, el proveedor, el repositorio elegido y los permisos de la cuenta; una conexión con credenciales caducadas se señala como tal.
El dock Pipelines
El dock Pipelines, en la parte inferior de la barra lateral, lista los pipelines de todas tus conexiones, agrupados por repositorio, con el estado de su última ejecución. La campana de una fila activa o desactiva las notificaciones de ese pipeline. Haz clic en un pipeline para abrirlo en una pestaña.
Los estados se actualizan automáticamente mientras trabajas. Para ahorrar cuota, una actualización cuesta dos llamadas por conexión, sea cual sea el número de pipelines; si el proveedor limita las llamadas, se siguen mostrando los últimos datos guardados con un aviso.

Leer una ejecución
La pestaña de un pipeline muestra sus ejecuciones por día, en directo: estado (Succeeded, Failed, Canceled, en curso…), commit, paso fallido, barra de progreso de los pasos, fecha y duración. El campo Filter runs… acepta varios filtros separados por punto y coma: fecha, parámetro, autor, ejecución, rama o estado. Run pipeline lanza una ejecución en la rama y con los parámetros que elijas.
Abre una ejecución para ver sus jobs y sus pasos con su duración, sus parámetros, sus repositorios y sus artefactos descargables. Distingue el resultado de la ejecución remota del de un ticket: un ticket terminado no demuestra que una nueva CI haya tenido éxito.

Abrir los logs en el primer error
En una ejecución fallida, la acción Open logs at the first error despliega directamente el paso que ha fallado. El campo Filter all logs… busca en todos los registros, Copy copia el log mostrado y la marca de tiempo de las líneas se activa en los ajustes del plugin.
Cada tarjeta de ejecución ofrece también: relanzar los jobs fallidos, relanzar la ejecución en la misma rama, cancelar una ejecución en curso y aprobar o rechazar un despliegue pendiente. Estas acciones actúan sobre tu servicio de CI: comprueba el destino antes de usarlas.

Crear un ticket de corrección
El botón Autofix this failed pipeline (Autofix) abre el diálogo de creación de ticket, ya rellenado: pipeline, definición, ejecución, enlace y extracto del primer registro fallido, censurado y limitado a 16 000 caracteres. Elige el agente, el modelo y el nivel de razonamiento, indica si hace falta las verificaciones locales y crea el ticket.
Una ejecución solo genera un ticket de reparación: volver a lanzar la acción recupera el mismo ticket. En los ajustes del plugin, Create a repair ticket automatiza la creación para cada nuevo fallo de un pipeline vigilado, y Require ticket approval los mantiene pendientes hasta que des tu aprobación. Cuando sus herramientas MCP están disponibles, el agente consulta el contexto de CI sin que tengas que copiar los registros: consulta los MCP internos.

Crear un pipeline con IA
En la parte inferior de la pestaña de un pipeline, la zona Create with AI acepta una descripción en lenguaje natural, por ejemplo «Pipeline nocturno: tests e2e de Playwright en macOS y Windows, informe HTML publicado como artefacto». Create pipeline ticket abre el diálogo de creación: el agente escribirá la definición YAML en el repositorio, dentro de su worktree, y tú la revisarás como cualquier otro cambio.

Seguir los tickets en Mission Control
Los tickets de reparación y de creación se suman al tablero como los demás: sigues su avance en Mission Control, lees el informe y revisas el diff antes de la integración. El informe debe distinguir las comprobaciones locales de los resultados remotos realmente consultados.

Acciones remotas y validación
Para una misión de IA, indica explícitamente qué acciones remotas están autorizadas: lanzar una ejecución, relanzar, aprobar un despliegue. Una corrección puede validarse con los tests y builds locales y, después, una persona lanza la CI remota.
Los comandos desde la app de iPhone Horizon se autorizan conexión por conexión, con Allow commands from Horizon. Una conexión no disponible, una cuota del proveedor o unas credenciales caducadas pueden retrasar la actualización: comprueba la fecha y el estado antes de sacar conclusiones.