Page Releases

1Santé des releases

Par release : adoption (part des sessions du projet), sessions sans crash, utilisateurs sans crash, événements, nouveaux problèmes, régressions et dernier deploy. Les taux sont arrondis vers le bas pour qu'un seul crash n'affiche jamais 100 %. Les sessions viennent des SDK Sentry, de POST /api/v1/sessions, ou du SDK navigateur avec autoSessionTracking: true et une release. Les sessions sont conservées 90 jours.

2Commits suspects

La page d'un problème liste jusqu'à cinq commits de la première release où le problème est apparu dont les fichiers modifiés correspondent à une frame applicative de la stack trace (les deux derniers segments du chemin doivent concorder, envoyez donc les source maps pour les bundles minifiés). Les commits viennent de l'API compare de GitHub quand un token est enregistré, sinon de ce que la CLI a envoyé.

3Token GitHub

Enregistrez un token par projet sur la page Code owners. Il est chiffré, seul un indice de 4+4 caractères est jamais affiché, et il n'est utilisé qu'auprès de api.github.com.

4Règles de code owners

Une règle associe un glob de chemin de fichier ou un motif d'URL à un e-mail ou à un libellé d'équipe comme #payments. Globs de chemin : src/checkout/**, *.py, models/*.py ; * reste dans un répertoire, ** traverse les répertoires, et un motif correspond à n'importe quelle frontière de répertoire. Les motifs d'URL comme */checkout* sont insensibles à la casse. Au plus 4 jokers et 256 caractères par motif, 200 règles par projet. Les responsables correspondants s'affichent sur la page du problème, et ceux qui sont des e-mails reçoivent des copies des alertes.

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

Bon à savoir

• Les régressions sur la page Releases comptent les problèmes qui avaient été résolus et sont revenus dans cette release.
• Les utilisateurs sans crash nécessitent des sessions avec un id utilisateur ; les comptes de sessions agrégés n'en ont pas.