Changelogs produits par les agents

Changelogs produits par les agents

Explorer, relire et interpréter les journaux générés automatiquement pour chaque commit

Consultez le détail des changelogs, lisez le contenu rendu en Markdown, suivez le statut d’exécution et regroupez les entrées pour une relecture efficace.

Ce que vous apprendrez ici

Affichage détaillé

Voir le détail de chaque changelog : titre, auteur, date, statut d’exécution et métadonnées associées.

Rendu Markdown

Lire le contenu généré avec rendu Markdown (titres, listes, code, liens) directement dans l’interface.

Statut d'exécution

Identifier rapidement si une génération est réussie, en erreur ou en attente grâce aux badges de statut.

Groupement et filtrage

Regrouper par branche, par développeur ou par commit pour structurer la relecture.

Traiter les commits récents

Relancer le traitement des derniers commits pour re-générer ou compléter les changelogs.

Consulter les diffs

Ouvrir le diff associé à un commit pour comparer ce qui a changé et valider le contenu généré.

Public ciblé

Ce guide s’adresse aux responsables de produit, releveurs de contenu, reviewers et développeurs qui veulent relire l’historique des générations sans entrer dans les détails techniques.

Introduction Ce guide explique pas à pas comment explorer les journaux de génération (changelogs) produits par les agents pour chaque commit : comment afficher les détails d’un changelog, lire le contenu en Markdown, interpréter les statuts d’exécution, regrouper les entrées et bonnes pratiques pour une relecture efficace.

Workflow — Ouvrir l'onglet Commits / Changelogs et naviguer dans les groupes

1

Étape 1

Ouvrez votre projet puis cliquez sur l’onglet “Commits” ou “Commits/Changelogs” dans la barre de navigation du projet.

2

Étape 2

Repérez les contrôles de filtrage en haut (branche, agent, développeur). Par défaut, tous les groupes sont affichés.

3

Étape 3

Appliquez un filtre si vous souhaitez limiter l’affichage : sélectionnez une branche précise, un agent (ex. “Summarize git diff”) ou un développeur.

4

Étape 4

La page affiche alors des “groupes” organisés par branche, chaque groupe contenant des sous-groupes par auteur et, pour chaque commit, les logs générés.

5

Étape 5

Cliquez sur un groupe (ou sur une entrée de commit) pour déplier et voir la liste des logs associés. Chaque log affiche un résumé (titre, agent, date) avant d’être développé.

6

Étape 6

Utilisez le bouton “Actualiser” si vous pensez que de nouvelles générateurs ont été exécutés depuis votre dernière visite.

7

Étape 1

Dans la liste des logs d’un commit, repérez la ligne du changelog qui vous intéresse. Les informations visibles d’emblée : titre, nom de l’agent, date/heure et badge de statut.

8

Étape 2

Cliquez sur la ligne pour déplier le changelog. L’interface affiche le contenu rendu en Markdown (titres, listes, blocs de code, liens) dans une zone “prose”.

9

Étape 3

Consultez en haut du panel le statut du log : success/completed, error, pending. Si une erreur est indiquée, notez le message résumé et la date d’exécution.

10

Étape 4

Si le changelog vous semble incomplet ou pose question, marquez-le pour revue (si votre projet propose un bouton “Marquer comme revu”) ou ajoutez un commentaire dans votre processus de revue.

11

Étape 5

Si nécessaire, exportez le contenu (bouton d’export Markdown ou JSON) pour archivage ou traitement externe.

12

Étape 1

Dans l’onglet Commits/Changelogs, localisez le bouton “Process recent commits” (ou “Traiter les commits récents”).

13

Étape 2

Cliquez sur ce bouton pour lancer une opération de rattrapage : le système simule des évènements push pour les commits récents et exécute les agents configurés.

14

Étape 3

Pendant le traitement, surveillez l’indicateur d’activité (animation du bouton ou bannière). Les exécutions peuvent déclencher plusieurs générations par agent selon les hooks configurés.

15

Étape 4

À la fin, actualisez la liste des changelogs pour visualiser les nouvelles entrées ou statuts mis à jour. Si certains logs sont en erreur, conservez les détails pour diagnostic.

16

Étape 5

Important : évitez de lancer cette opération en boucle sur de larges périodes sans filtrage — cela peut générer de nombreuses exécutions. Préférez limiter la fenêtre ou le nombre de commits à traiter.

17

Étape 1

Dans la vue d’un commit, repérez la mention du commit (hash ou identifiant court) affichée à côté de la date.

18

Étape 2

Cliquez sur le commit pour ouvrir le panneau de détails. L’interface propose généralement un lien ou un bouton “Voir le diff” ou “Afficher les changements”.

19

Étape 3

Le diff s’ouvre : vérifiez les fichiers modifiés, les ajouts/suppressions et contextualisez le contenu généré par rapport aux lignes modifiées.

20

Étape 4

Utilisez le diff pour confirmer que le changelog reflète bien les changements effectifs (ex. le résumé mentionne bien les fichiers/fonctions modifiés).

21

Étape 5

Si le changelog semble décalé par rapport au diff, signalez-le dans votre workflow de revue ou relancez le traitement pour ce commit.

Tip — Filtrez intelligemment pour gagner du temps

Pour les revues récurrentes, créez un ordre de travail : 1) filtres par branche stable (ex. main), 2) logs récents non revus, 3) logs en erreur. Cela réduit le bruit et concentre l’effort là où il y a le plus de valeur.

Attention — Sur-traitement et doublons possibles

Le traitement des commits récents simule des événements et peut lancer plusieurs exécutions d’agents. N’exécutez pas cette opération sans vérification si vous traitez des centaines de commits : vous risquez de générer des doublons ou d’épuiser des quotas liés aux exécutions.

Bonnes pratiques — Relire l'historique des générations (processus recommandé)

1

Étape 1 — Planifiez votre session

Définissez un objectif (ex. revue quotidienne, vérification de sécurité, préparation d’une release). Limitez la période à relire (ex. derniers 7 jours).

2

Étape 2 — Appliquez des filtres

Filtrez par branche et par agent pour ne voir que les changelogs pertinents. Par exemple, pour vérifier des notes de sécurité, filtrez sur l’agent “Daily Changelog” ou sur la branche de release.

3

Étape 3 — Priorisez par statut

Commencez par les logs en erreur, puis par les logs non revus, et enfin par les logs marqués completed. Cela maximise la valeur produite par la relecture.

4

Étape 4 — Utilisez le diff comme source de vérité

Pour chaque changelog, consultez le diff du commit associé pour valider l’exactitude du texte généré.

5

Étape 5 — Regroupez les actions et documentez

Notez les corrections à apporter (titres, omissions, erreurs factuelles) et marquez les logs comme “revu” ou “à corriger”. Si un même commit a plusieurs logs, traitez-les ensemble pour cohérence. :

6

Étape 6 — Établissez des règles de qualité

Définissez des critères (ex. longueur minimale, présence d’un résumé, sections obligatoires) et appliquez-les systématiquement lors des revues.

7

Lecture rapide (scan)

  • Sélectionnez la branche principale.
  • Filtrez sur les 24–72 dernières heures.
  • Parcourez uniquement les titres et statuts ; ouvrez les logs en erreur ou ceux avec balises “summary”.
  • Temps estimé : 10–30 minutes.
8

Relecture approfondie (release)

  • Filtrez sur la branche de release et la période de la release candidate.
  • Ouvrez chaque commit, consultez le diff et l’ensemble des logs associés.
  • Vérifiez cohérence entre logs multiples du même commit.
  • Documentez corrections et marquez comme approuvé.
9

Audit de sécurité / conformité

  • Filtrez sur agents dédiés aux security/daily summaries.
  • Recherchez mots-clés (vulnérabilité, CVE, patch).
  • Vérifiez que les références (versions, CVE) sont exactes et complètes.

Avant — Relecture ad hoc

  • Beaucoup de bruit : tous les logs mélangés.
  • Risque d’oublier des erreurs.
  • Temps perdu à retrouver le contexte.

Après — Relecture structurée

  • Filtrage par branche/agent/développeur.
  • Priorisation des erreurs et non-revus.
  • Utilisation systématique du diff pour vérification.

Tip — Grouper pour prendre du recul

Lorsque plusieurs logs proviennent du même commit (même hash), ouvrez le groupe complet et lisez toutes les entrées ensemble. Cela évite de valider une entrée hors contexte et garantit la cohérence entre résumés et analyses secondaires.

Limites du groupement automatique

Le groupement automatique peut masquer des logs importants si vous filtrez trop finement (par agent ou développeur). Vérifiez toujours le nombre total de commits et de logs affichés après application d’un filtre.

Frequently Asked Questions

Résumé & actions rapides

  • Toujours commencer par les logs en erreur.
  • Filtrer par branche/agent/développeur pour réduire le bruit.
  • Utiliser le diff pour valider le contenu généré.
  • Traiter les commits récents avec modération pour éviter doublons.
  • Documenter les corrections et établir des règles qualité.

Prêt à revoir vos changelogs ?

Accédez directement à l’onglet Commits/Changelogs de votre projet pour appliquer ces bonnes pratiques et commencer la relecture structurée.