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.
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
- En Workspace › Integraciones, selecciona la tarjeta GitHub.
- Selecciona Instalar en GitHub. GitHub se abre en la misma pestaña.
- Elige la cuenta u organización de GitHub en la que instalar la aplicación.
- Elige All repositories o Only select repositories y marca los que quieras. Puedes cambiarlo más adelante en GitHub sin volver a Probara.
- 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.
- 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:
- Abre Configuración › GitHub del proyecto.
- En Repositorios de GitHub, selecciona los repositorios con los que trabaja este proyecto.
- Si quieres, marca uno como Predeterminado. Aparece preseleccionado al crear un issue.
- 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 |
- Selecciona Vincular issue de GitHub.
- Elige un Repositorio.
- En Issue, escribe palabras del título o
#123para buscar por número. - En Vincular como, deja el tipo predeterminado o cámbialo.
- 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.
Trazabilidad con GitHub
Los issues de GitHub pueden ser los requisitos de un informe de trazabilidad. 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.
- Vincula los issues como Requisito en los casos de prueba que los verifican.
- En Trazabilidad del proyecto, selecciona Crear informe. Si Jira también está conectado, elige GitHub en Herramienta de seguimiento.
- Elige uno o varios en Repositorio (hasta 20). La lista sigue los repositorios del proyecto.
- 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.
- 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.
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.
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 o a través de Probara 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, y cada herramienta MCP en la referencia de herramientas MCP.