Página de Releases

1Salud de la release

Por release: adopción (cuota de las sesiones del proyecto), sesiones sin fallos, usuarios sin fallos, eventos, incidencias nuevas, regresiones y el último deploy. Las tasas se redondean hacia abajo para que un fallo nunca se muestre como 100%. Las sesiones vienen de los SDKs de Sentry, de POST /api/v1/sessions o del SDK de navegador con autoSessionTracking: true y una release. Las sesiones se conservan 90 días.

2Commits sospechosos

La página de una incidencia lista hasta cinco commits de la primera release en la que apareció la incidencia cuyos archivos modificados coinciden con un frame in-app del stack (los dos últimos segmentos de la ruta deben coincidir, así que sube source maps para los bundles minificados). Los commits vienen de la API compare de GitHub cuando hay un token guardado, o si no, de lo que envió la CLI.

3Token de GitHub

Guarda un token por proyecto en la página de Code owners. Está cifrado, solo se muestra una pista de 4+4 caracteres y se usa únicamente contra api.github.com.

4Reglas de code owners

Una regla asocia un glob de ruta de archivo o un patrón de URL a un correo o a una etiqueta de equipo como #payments. Globs de ruta: src/checkout/**, *.py, models/*.py; * se queda dentro de un directorio, ** cruza directorios y un patrón coincide en cualquier límite de directorio. Los patrones de URL como */checkout* no distinguen mayúsculas. Como máximo 4 comodines y 256 caracteres por patrón, 200 reglas por proyecto. Los responsables coincidentes se muestran en la página de la incidencia, y los que son correos reciben copias de las alertas.

src/checkout/**      ana@example.com
models/*.py          #odoo-team
*/checkout*          payments@example.com

Conviene saber

• Las regresiones en la página de Releases cuentan las incidencias que se resolvieron y volvieron en esa release.
• Usuarios sin fallos necesita sesiones con id de usuario; los recuentos agregados de sesiones no lo tienen.