GitHub se conecta ya sea mediante la Coroid Aplicación GitHub o un token de acceso personal. Configúrelo en Configuración → Conexiones → Control de código fuente.
Aplicación o token
Es preferible usar la aplicación. Esta otorga acceso por repositorio en lugar de por usuario, sigue funcionando cuando la persona que la configuró se marcha y recibe eventos de webhook sin necesidad de realizar sondeos.
Utilice un token cuando la instalación de la aplicación requiera una aprobación de administrador de organización que no pueda obtener.
| Aplicación GitHub | Token de acceso personal | |
|---|---|---|
| Ámbito de acceso | Por repositorio | Todo lo que el usuario pueda ver |
| Sigue activa aunque el instalador se marche | Sí | No |
| Eventos de webhook | Sí | Sondeo |
| Atribución | La aplicación | El propietario del token |
Instalación de la aplicación
Seleccione GitHub en Configuración → Conexiones → Control de código fuente y siga el flujo de instalación. GitHub le preguntará qué repositorios concederle acceso; podrá modificar esto más tarde desde la configuración propia de GitHub.
Si un repositorio no aparece al crear un proyecto, es muy probable que la aplicación no haya recibido permiso para ese repositorio específico; esta es, con diferencia, la causa más común.
Uso de un token
Cree un token clásico con el ámbito repo , o un token de gran precisión con permisos de lectura y escritura sobre contenidos y solicitudes de extracción, y luego pégalo en la configuración del control de versiones.
Los tokens se cifran en reposo, nunca los devuelve API y nunca se incluyen en las exportaciones de configuración.
Incidencias de GitHub
La misma conexión permite importar incidencias como tareas. Consulte Importación de tareas.
Eventos que se convierten en tareas
Con la aplicación, una automatización de eventos puede enviar un pull request, una nueva incidencia o un comentario que mencione a Coroid a Qualification. Consulte Desencadenadores y destinos.
El trabajo cualificado procedente de estos eventos solo se inicia por sí solo cuando su autor tiene permisos de escritura, mantenimiento o administración en el repositorio. Coroid consulta a GitHub para cada evento. En el caso de una pull request, el autor es la persona que la abrió, no quien la etiquetó o fusionó. El trabajo generado por otras personas se crea y espera a que alguien lo inicie. Un comentario que mencione a Coroid solo cuenta si su autor tiene permisos de escritura.
Revisión de solicitudes de extracción
Con la aplicación, Coroid verifica y revisa las solicitudes de extracción que abren personas y otras herramientas, no solo las propias de Coroid. El Control de Calidad de Coroid ejecuta las comprobaciones del proyecto y publica la comprobación de Control de Calidad de Coroid. La Revisión de Coroid publica una revisión con comentarios en las líneas que cuestiona, y una comprobación llamada Revisión de Coroid. Ambas se configuran en Control de Calidad, bajo Solicitudes de extracción. Consulte Solicitudes de extracción.
Qué hace Coroid en su repositorio
- lee el código para entenderlo y modificarlo
- crea una rama por tarea
- envía esa rama y abre una solicitud de extracción de pull request contra su rama base
Nunca realiza commits en su rama predeterminada ni fusiona por sí sola. La fusión solo ocurre cuando una persona fusiona la pull request en GitHub o pulsa Aprobar y fusionar en Coroid.
Un proyecto configurado como Solo local realiza la primera de estas acciones y nada más: Coroid lee y extrae datos, y mantiene ramas, revisiones y comprobaciones dentro de Coroid. No envía, abre ni comenta en solicitudes de extracción, ni publica ejecuciones de comprobaciones, incluso cuando la aplicación o el token lo permitieran. Consulte Sincronizado o solo local.
Su protección de ramas, comprobaciones obligatorias y reglas de revisión se aplican sin cambios. Aprobar y fusionar también fusiona a través de pull request, por lo que las mismas reglas determinan si tiene éxito. Consulte Fusión.