# Integración con GitHub > Instala la GitHub App de Probara, vincula issues a casos de prueba, ejecuciones y defectos, crea issues a partir de fallos y mantén sincronizado el estado de los defectos. La integración con **GitHub** conecta cuentas de GitHub con tu organización de Probara a través de la GitHub App de Probara. Una vez instalada, tu equipo puede: - vincular issues de GitHub a casos de prueba, ejecuciones y defectos; - crear un issue de GitHub a partir de un defecto o de un resultado fallido, con el caso de prueba ya incluido; - mantener sincronizados un defecto y sus issues: al resolver el defecto se cierra el issue, y al cerrar el issue se resuelve el defecto; - crear informes de trazabilidad a partir de issues de GitHub; - lanzar ejecuciones automatizadas en GitHub Actions y recibir un comentario con los resultados en cada pull request. Esa parte tiene su propia guía: [Ejecutar pruebas con GitHub Actions](https://docs.probara.net/es/guides/integrations/github-actions/). ## Antes de empezar | Necesitas | Por qué | | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Un plan de pago (**Pro** o **Enterprise**, o una prueba Pro) | Las integraciones no forman parte del plan Free. En Free, el diálogo de GitHub muestra **Ver planes** en lugar de **Instalar en GitHub**. | | Un **propietario** o **administrador** de Probara | Solo los propietarios y administradores pueden instalar la aplicación, desconectar una cuenta y elegir los repositorios de un proyecto. | | Un propietario de la organización de GitHub, o el titular de la cuenta personal | GitHub solo les permite a ellos instalar aplicaciones en la cuenta. | | Un repositorio en **github.com** | GitHub Enterprise Server no es compatible. | ## Instalar la GitHub App 1. En **Workspace › Integraciones**, selecciona la tarjeta **GitHub**. 2. Selecciona **Instalar en GitHub**. GitHub se abre en la misma pestaña. 3. Elige la cuenta u organización de GitHub en la que instalar la aplicación. 4. Elige **All repositories** o **Only select repositories** y marca los que quieras. Puedes cambiarlo más adelante en GitHub sin volver a Probara. 5. Aprueba la instalación. A continuación GitHub te pide que autorices a Probara: así Probara comprueba que tu cuenta de GitHub tiene acceso a la instalación antes de asociarla a tu organización. 6. GitHub te devuelve a Probara, que muestra **GitHub está conectado**. Selecciona **Ir a Integraciones**. La cuenta aparece ahora en **Cuentas conectadas** dentro del diálogo de GitHub, con su acceso a repositorios (**Todos los repositorios** o **Repositorios seleccionados**) y el estado **Activa**. Selecciona **Ver repositorios** para ver a cuáles llega la aplicación. La conexión pertenece a tu organización de Probara. Nadie de otra organización puede ver sus repositorios, y una instalación solo puede estar conectada a una organización de Probara a la vez. Para trabajar con varias cuentas u organizaciones de GitHub, instala la aplicación en cada una. El enlace de instalación es válido durante 10 minutos y funciona una sola vez. Si caducó, vuelve a empezar desde **Instalar en GitHub**. ### Qué puede hacer la aplicación en GitHub GitHub muestra estos permisos al instalar la aplicación: | Permiso | Acceso | Para qué | | ------------- | --------- | -------------------------------------------------------------------- | | Metadata | Lectura | Listar los repositorios a los que diste acceso | | Contents | Lectura | Listar las ramas al lanzar un workflow | | Issues | Escritura | Buscar, crear, cerrar y reabrir issues | | Actions | Escritura | Listar los workflows e iniciarlos | | Pull requests | Escritura | Publicar el comentario de resumen de la ejecución en un pull request | La aplicación también recibe los eventos de issues y de ejecuciones de workflows de GitHub: así llegan a Probara los cambios de estado y las novedades de cada build. ## Elegir los repositorios de un proyecto De forma predeterminada, un proyecto ofrece **todos los repositorios que ve la aplicación de GitHub** al vincular un issue, crear uno o lanzar un workflow. Para acotarlos: 1. Abre **Configuración › GitHub** del proyecto. 2. En **Repositorios de GitHub**, selecciona los repositorios con los que trabaja este proyecto. 3. Si quieres, marca uno como **Predeterminado**. Aparece preseleccionado al crear un issue. 4. Selecciona **Guardar repositorios**. En cuanto hay al menos un repositorio seleccionado, el proyecto usa **solo** esos repositorios: los vínculos, las búsquedas, los issues nuevos, los informes de trazabilidad, los lanzamientos de workflows y los comentarios en pull requests quedan limitados a ellos. Quita todos los repositorios para volver a ofrecerlos todos. ## Vincular issues de GitHub Puedes vincular issues en tres sitios: | Dónde | Sección | Tipo predeterminado | | -------------- | ------------------------------------------------------------------ | ------------------- | | Caso de prueba | Pestaña **Propiedades** o el editor completo, **Issues de GitHub** | **Requisito** | | Ejecución | Pestaña **Defectos**, **Issues de GitHub** | **Defecto** | | Defecto | Página del defecto, **Issues de GitHub** | **Defecto** | 1. Selecciona **Vincular issue de GitHub**. 2. Elige un **Repositorio**. 3. En **Issue**, escribe palabras del título o `#123` para buscar por número. 4. En **Vincular como**, deja el tipo predeterminado o cámbialo. 5. Selecciona el issue en la lista y haz clic en **Vincular issue**. El tipo indica para qué sirve el vínculo: - **Requisito**: el issue describe lo que verifica el caso. Los vínculos de tipo requisito en casos de prueba son lo que los informes de trazabilidad cuentan como cobertura. - **Defecto**: el issue sigue un error. Los vínculos de tipo defecto en un defecto mantienen su estado sincronizado con el issue (consulta más abajo). Vincular un issue existente no escribe nada en GitHub. Para quitar un vínculo, selecciona la **×** junto a él y confirma: el issue sigue en GitHub. ### Datos y vista previa del issue Cada vínculo muestra el issue como `propietario/repositorio#número`, su título, su tipo y su estado (**Abierto** o **Cerrado**). Pasa el cursor sobre la referencia para ver sus etiquetas, quién lo abrió y cuándo lo leyó Probara por última vez en GitHub, junto con **Abrir en GitHub**. Probara guarda una copia de estos datos y la actualiza cada vez que GitHub informa de un cambio en el issue. Si GitHub no responde, los vínculos siguen mostrando los últimos datos leídos. Selecciona **Actualizar desde GitHub** en un vínculo para volver a leerlo en ese momento. ## Crear un issue desde un defecto o un resultado fallido - **Desde un defecto:** en la página del defecto, en **Issues de GitHub**, selecciona **Crear issue de GitHub**. - **Desde un resultado fallido:** al reportar un defecto desde un resultado fallido o bloqueado, marca **Crear también un issue de GitHub** en el diálogo **Reportar defecto**. Cuando el defecto se guarda, se abre el diálogo de creación. En **Crear un issue de GitHub**, elige el **Repositorio**, revisa el **Título** y la **Descripción**, elige si quieres **Etiquetas** de ese repositorio y selecciona **Crear issue**. El issue queda vinculado al defecto como vínculo de tipo **Defecto**. El texto viene precargado y puedes editarlo todo: | Precargado desde | Título | Descripción | | -------------------- | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Un defecto | El título del defecto | La descripción del defecto y enlaces a sus adjuntos | | Un resultado fallido | El título del caso de prueba | Además, el caso de prueba, sus precondiciones, sus pasos con el resultado esperado y el real, el comentario del fallo, y la ejecución, el entorno y la configuración | La descripción termina con enlaces de vuelta al defecto, al caso de prueba y a la ejecución en Probara, y con el nombre de quien lo creó. En GitHub, el autor del issue es la aplicación de Probara. **Los adjuntos se quedan en Probara.** La descripción enlaza a cada archivo; para abrirlo hace falta acceso al proyecto en Probara. **Reintentar es seguro.** Si GitHub no confirma el issue nuevo, Probara te lo indica. Vuelve a intentarlo en un momento: Probara busca primero el issue que ya abrió y solo crea uno si no lo encuentra. ## Sincronización de estados Un defecto y los issues de GitHub vinculados a él como **Defecto** mantienen su estado sincronizado en ambos sentidos. Los vínculos de tipo **Requisito**, y los vínculos en casos de prueba y ejecuciones, nunca cambian un estado. | Cuando ocurre esto | En el otro lado | | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | El defecto pasa a **Resuelto** o **Cerrado** con resolución **Corregido**, o sin resolución | El issue se cierra como completado | | El defecto pasa a **Resuelto** o **Cerrado** con otra resolución | El issue se cierra como no planificado (_not planned_) | | El defecto se reabre desde **Resuelto** o **Cerrado** | El issue se reabre | | El issue se cierra como completado (o como duplicado) | El defecto pasa a **Resuelto**, con resolución **Corregido** | | El issue se cierra como no planificado | El defecto pasa a **Resuelto**, con resolución **No se corregirá** | | El issue se reabre | Un defecto **Resuelto** o **Cerrado** vuelve a **Abierto** | **En progreso** no se sincroniza: mover un defecto entre **Abierto** y **En progreso** no cambia nada en GitHub. Un defecto con varios issues vinculados sigue a cada uno de ellos, y su cambio se aplica a todos sus otros issues. Los cambios que llegan desde GitHub aparecen en la actividad del defecto como hechos por el sistema. Si GitHub no está disponible cuando cambia un defecto, Probara sigue reintentándolo durante un máximo de 7 días. ## Comentarios en pull requests Cuando se cierra o se aborta una ejecución reportada desde GitHub Actions para un pull request, Probara puede publicar sus resultados en ese pull request: el desenlace, una tabla con los recuentos, la tasa de éxito, la duración y el commit, hasta 10 casos fallidos o bloqueados, cada uno con un enlace **View result** a ese caso dentro de la ejecución, y las ejecuciones anteriores del pull request. Cada comentario es nuevo, así que el pull request avisa a sus participantes, y Probara oculta su comentario anterior como desactualizado. Un comentario oculto sigue en el pull request: selecciona **Show comment** para leerlo. Elige cuándo comenta un proyecto en su **Configuración › GitHub**, en **Comentarios en pull requests** (propietarios y administradores): | Opción | Comenta | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Después de cada run | Cada ejecución cerrada o abortada. | | Solo cuando fallan pruebas | Una ejecución con casos fallidos o bloqueados, o una ejecución abortada. Cuando una ejecución posterior pasa, un comentario más lo indica. | | Nunca | Nada. | **Solo cuando fallan pruebas** es la opción predeterminada. Una ejecución solo recibe comentario si registra el pull request de GitHub Actions para el que se ejecutó. Consulta [Ejecutar pruebas con GitHub Actions](https://docs.probara.net/es/guides/integrations/github-actions/#comentarios-en-pull-requests). ## Trazabilidad con GitHub Los issues de GitHub pueden ser los requisitos de un [informe de trazabilidad](https://docs.probara.net/es/guides/integrations/jira-traceability/). Los informes, las versiones, los filtros y la exportación a CSV funcionan igual que con Jira; solo cambia la forma de elegir los requisitos. 1. Vincula los issues como **Requisito** en los casos de prueba que los verifican. 2. En **Trazabilidad** del proyecto, selecciona **Crear informe**. Si Jira también está conectado, elige **GitHub** en **Herramienta de seguimiento**. 3. Elige uno o varios en **Repositorio** (hasta 20). La lista sigue los repositorios del proyecto. 4. Si quieres, acota los issues: - **Etiquetas**: los issues deben tener **todas** las etiquetas seleccionadas. Déjalo vacío para aceptar cualquier etiqueta. - **Hito**: el título de un hito. Un repositorio sin ese hito no aporta issues. - **Estado del issue**: **Abiertos y cerrados** (predeterminado), **Abiertos** o **Cerrados**. 5. Selecciona **Crear informe**. Los pull requests nunca son requisitos. En una versión, cada requisito aparece como `propietario/repositorio#número` con el estado **Open**, **Closed** o **Closed as not planned**, tal como lo nombra GitHub; el filtro **Estado del requisito** cuenta los issues abiertos como Por hacer y los cerrados como Hecho. Un caso de prueba cubre un issue cuando lo vincula como **Requisito**. ## Desconectar o desinstalar | Objetivo | Dónde | Qué ocurre | | ------------------------------ | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Dejar de usar una cuenta | **Workspace › Integraciones › GitHub**, selecciona **Desconectar** en la cuenta y confirma. | Probara deja de trabajar con sus repositorios. La aplicación sigue instalada en GitHub hasta que la desinstales allí. | | Quitar la aplicación de GitHub | En GitHub, desinstala la aplicación de Probara desde las GitHub Apps instaladas en la cuenta. | La cuenta aparece como **Requiere atención** en Probara. Desconéctala allí. | Una instalación suspendida también aparece como **Requiere atención** hasta que la reactives en GitHub. Los vínculos ya hechos siguen visibles con los últimos datos que leyó Probara. ## Solución de problemas | Mensaje | Qué hacer | | ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | «La aplicación de GitHub aún no está disponible en este entorno.» | La aplicación no está configurada para tu entorno. Contacta con el soporte de Probara. | | «Tu cuenta de GitHub no puede ver esta instalación. Instala la aplicación con una cuenta de GitHub que la administre.» | Vuelve a instalar desde Probara con una cuenta de GitHub que sea propietaria o administradora de la cuenta u organización. | | «Esta instalación de GitHub ya está conectada a un espacio de trabajo.» | La instalación pertenece a otra organización de Probara. Desconéctala allí primero. | | «Este enlace de instalación no es válido o ha caducado. Vuelve a empezar desde Integraciones.» | Selecciona de nuevo **Instalar en GitHub**. | | «GitHub ya no permite que Probara use esta instalación. Revisa la cuenta en Integraciones.» | La aplicación se desinstaló o se suspendió en GitHub. Reactívala, o desconecta la cuenta y vuelve a instalar la aplicación. | | «Este proyecto no vincula issues de ese repositorio.» | **Configuración › GitHub** del proyecto deja fuera ese repositorio. Un propietario o administrador puede añadirlo. | | «La instalación de GitHub no tiene acceso a este repositorio.» | En GitHub, da acceso a la aplicación a ese repositorio (ajuste **Repository access** de la instalación). | | «Ese número corresponde a un pull request. Solo se pueden vincular issues.» | Los pull requests no se pueden vincular. Elige un issue. | | «Los issues están desactivados en este repositorio de GitHub.» | Activa **Issues** en la configuración del repositorio en GitHub, o elige otro repositorio. | | «GitHub rechazó el issue. Revisa las etiquetas y vuelve a intentarlo.» | Quita las etiquetas que ya no existen en el repositorio. | | No aparece el botón **Vincular issue de GitHub** | No hay ninguna cuenta de GitHub conectada, tu plan no incluye integraciones o tu rol no puede editar ese caso, ejecución o defecto. | Los errores al lanzar un workflow, como uno que no se puede iniciar, están en [Ejecutar pruebas con GitHub Actions](https://docs.probara.net/es/guides/integrations/github-actions/#solución-de-problemas). ## Seguridad y datos - **Credenciales.** Probara no guarda contraseñas ni tokens personales de GitHub. Actúa como la aplicación, con tokens de corta duración limitados a los repositorios a los que diste acceso, y solo desde los servidores de Probara. - **Qué guarda Probara:** el nombre de la cuenta conectada y, por cada vínculo, el repositorio, el número del issue, su título, estado, etiquetas, autor y URL. - **Qué escribe Probara en GitHub:** los issues que creas, el cierre y la reapertura de los issues vinculados a defectos como **Defecto**, y el comentario de resumen en los pull requests. - **Auditoría.** Conectar y desconectar cuentas, cambiar los repositorios de un proyecto o su ajuste de comentarios en pull requests, vincular, desvincular y crear issues, y lanzar workflows queda registrado en la [actividad del workspace](https://docs.probara.net/es/guides/workspace/activity/). ## Automatizar con la API y MCP Los scripts y los asistentes de IA pueden hacer el trabajo diario con GitHub con un [token de API](https://docs.probara.net/es/developers/authentication/) o a través de [Probara MCP](https://docs.probara.net/es/developers/mcp/): listar, vincular, actualizar y desvincular issues en casos de prueba, ejecuciones y defectos; buscar issues de un repositorio; crear un issue desde un defecto; consultar los repositorios de un proyecto, y lanzar workflows. Instalar la aplicación, desconectar una cuenta, elegir los repositorios de un proyecto y activar o desactivar los comentarios en pull requests se hace solo desde la aplicación web. Los endpoints están en la página [API de GitHub](https://docs.probara.net/es/developers/api/github/), y cada herramienta MCP en la [referencia de herramientas MCP](https://docs.probara.net/es/developers/mcp-tools/).