Cada proyecto apunta a un repositorio. La configuración de dicho repositorio determina cómo Coroid interactúa con tu modelo de ramificaciones.
Puedes encontrarla en la configuración del proyecto.
Sincronizado o solo local
El modo del repositorio decide si Coroid puede escribir en GitHub o GitLab.
- Sincronizado (el valor predeterminado): Coroid envía la rama de cada tarea y abre solicitudes de extracción contra tu rama base.
- Solo local: Coroid clona y extrae datos del repositorio, pero nunca escribe en él. No hay envíos, ni ramas remotas, ni solicitudes de extracción, comentarios, revisiones, ejecuciones de comprobación ni webhooks, ni fusiones ni ejecuciones de pipelines. Las ramas, confirmaciones, revisiones, pruebas y vistas previas ocurren todas dentro de Coroid.
Sincronizado
- Extrae datos de GitHub
- Envía ramas y abre pull requests
Solo local
- Extrae datos de GitHub
- Nunca envía, comenta ni abre pull requests
- Obtiene sus ramas del propio git de Coroid
Selecciona el modo al crear el proyecto y cámbialo en la configuración del mismo. Un proyecto solo local muestra Solo local junto al nombre del repositorio.
El modo solo local es la forma segura de probar Coroid en un repositorio real. Las tareas y los planes se ejecutan hasta la fase de revisión. En lugar de un pull request, la revisión muestra Almacenado en Coroid y una acción: Iniciar sincronización. Para aprobar se necesita un proyecto sincronizado, ya que la aprobación implica fusionar en tu rama base; dentro de un plan, las tareas siguen agrupándose en la rama del plan en Coroid. La copia que Coroid tiene de tu rama base permanece idéntica a la remota, por lo que nada llega a ella sin que hayas abierto un pull request.
Para ver el trabajo en tu propia máquina, abre Clonar y exportar en la configuración del repositorio, crea un token de acceso y obtén las ramas de Coroid desde su propio git:
git remote add coroid https://coroid@git.coroid.ai/git/<project-id>.git
git fetch coroidIniciar sincronización cambia el proyecto a modo Sincronizado. A partir de ese momento, el nuevo trabajo se envía y genera solicitudes de extracción. El trabajo ya almacenado en Coroid permanece donde está: abre su pull request desde la página de revisión (Crear pull request para una tarea, Abrir pull request para un plan). Cambiar de nuevo a modo Solo local surte efecto de inmediato.
Nada en el modo solo local depende del alcance de tu token: Coroid rechaza cualquier escritura en el repositorio, independientemente de lo que permita la conexión. Este modo se adapta a la configuración de ramas del proyecto en Portabilidad de la configuración.
Rama base
Coroid parte de tu rama base y abre solicitudes de incorporación de cambios contra ella. Por defecto, se utiliza la rama predeterminada del repositorio.
Cámbiala si deseas fusionar en otro lugar: una develop rama, un tren de lanzamientos o una rama de integración de larga duración. Un error en esta configuración es el fallo más común y genera solicitudes de incorporación de cambios dirigidas a una rama que nadie revisa.
Cuando cambia la rama de destino
Un plan registra el commit de la rama base desde el cual comienza. Si la rama base cambia antes de que se fusione el pull request del plan, Coroid detiene la fusión; consulta Cuando se mueve la rama base. Esta configuración define lo que sucederá a continuación:
- Pausar para revisión (por defecto): alguien examina los nuevos commits y, bien los acepta, bien solicita a Coroid que los fusione y vuelva a verificarlos.
- Fusionar y volver a verificar — Coroid fusiona los cambios en la rama del plan y ejecuta nuevamente los procesos de desarrollo, control de calidad y revisión sin esperar a nadie. Esto consume horas de agente. Si la fusión o la re-verificación fallan, la decisión recae en una persona.
En cualquier caso, nada se fusiona hasta que el plan se haya comprobado frente a la rama base actual o una persona haya aceptado las diferencias. Esta configuración forma parte de los ajustes de ramas del proyecto, por lo que se traslada junto con ellos en portabilidad de configuraciones.
Ramas de trabajo
Cada tarea se desarrolla en su propia rama. Las ramas se crean por tarea y se envían cuando el trabajo está listo (en un proyecto de tipo local solo, se almacenan en Coroid); así, dos tareas ejecutándose simultáneamente nunca comparten la misma rama ni pueden ver el trabajo en curso del otro.
Nada se confirma nunca directamente en tu rama base. No se trata de una configuración; es una característica intrínseca del funcionamiento de Coroid.
Una rama por tarea. Dos tareas nunca comparten una rama.
Tus revisiones y comprobaciones requeridas se aplican sin cambios.
Tú fusionas en main
Protección de ramas
Tu protección de ramas existente se aplica sin cambios. Coroid abre una solicitud de incorporación de cambios ordinaria, por lo que las revisiones obligatorias, las comprobaciones de estado necesarias y las restricciones sobre quién puede fusionar se comportan igual que para tu equipo.
Si tus reglas de protección exigen commits firmados o una comprobación de estado específica que Coroid no pueda generar, el pull request se abrirá y permanecerá sin poder fusionarse: eso se debe a que tus reglas funcionan correctamente, no a un fallo de Coroid.
Limpieza
Las ramas del trabajo finalizado pueden eliminarse después de que su pull request se fusione o cierre. Si dependes de los nombres de las ramas para auditorías o herramientas de lanzamiento, verifica esta opción antes de activarla.
Cambiar la conexión
Si la conexión al repositorio subyacente cambia —por ejemplo, al rotar un token, reinstalar una aplicación o renombrar un repositorio— el proyecto conservará su identidad e historial. Reorienta la conexión hacia la nueva sin crear un proyecto nuevo, para no perder contexto, configuraciones y trabajo previo.
Configuración de la canalización de lanzamientos
La rama base determina dónde Coroid abre las solicitudes de extracción. El despliegue utiliza un proyecto separado. Lanzamiento Configuración de lanzamiento: un entorno, su política de disponibilidad y, opcionalmente, una referencia de canalización GitLab o acciones GitHub, además de un trabajo de despliegue. La referencia debe apuntar al commit bloqueado del lanzamiento antes de que Coroid solicite su ejecución. Configure una credencial de devolución de llamada con alcance de entorno para que la canalización pueda informar sobre su resultado; la simple conexión al repositorio no confirma qué se ha desplegado. Las canalizaciones externas pueden reportar eventos sin necesidad de habilitar la activación desde Coroid.