Discourse GitHub

[Discourse]

	Résumé	Discourse GitHub Permet au personnel d’attribuer des badges aux utilisateurs en fonction de leurs contributions GitHub. Permet également aux utilisateurs de créer des Linkbacks GitHub, des Permalinks et d’afficher le statut en direct des PR dans les oneboxes.
	Guide d’installation	Ce plugin est intégré au noyau de Discourse. Il n’est pas nécessaire d’installer le plugin séparément.

Comme il s’agit d’un plugin official maintenu par l’équipe Discourse, les demandes de Support, de Contribute > Bug, de Contribute > UX et de Contribute > Feature peuvent être faites dans les catégories respectives ici sur Meta, et taguées avec le tag de plugin approprié. Cliquez sur un lien ci-dessous pour en créer un.

 Support  Bug  UX  Fonctionnalité

Fonctionnalités

Badges GitHub

Attribuez des badges à vos utilisateurs en fonction de leurs contributions GitHub.

Comment utiliser :

1. Activez github badges enabled dans Paramètres → Plugins.
2. Générez un jeton d’accès GitHub et collez-le dans le paramètre github linkback access token. Voir ci-dessous pour les instructions.
3. Ajoutez une ou plusieurs URL des dépôts GitHub à scanner pour les contributions dans le paramètre site github badges repos.

Comment fonctionne le comptage des badges :

Les badges comptent les commits sur tous les dépôts, et lorsqu’un utilisateur contribue à plusieurs dépôts, tous leurs commits sont additionnés dans un total unique.

Badges de Commiteur :

Badge	Commits Requis
Bronze	1 commit
Argent	25 commits
Or	1000 commits

Progression des Badges : Au fur et à mesure que les utilisateurs accumulent plus de contributions sur n’importe lequel des dépôts suivis, ils progressent automatiquement à travers les niveaux de badges. Par exemple, si un utilisateur fait un commit sur le Dépôt A, puis sur le Dépôt B, les deux contributions comptent pour leur total, leur permettant de passer de Bronze à Argent, puis à Or.

---

Linkback GitHub

Créez un lien depuis une pull request ou un commit GitHub vers un message Discourse où il est mentionné.

Comment utiliser :

1. Activez github linkback enabled dans Paramètres → Plugins.
2. Générez un jeton d’accès GitHub et collez-le dans le paramètre github linkback access token. Voir ci-dessous pour les instructions.
3. Enfin, ajoutez les projets vers lesquels vous souhaitez poster dans le paramètre site github linkback projects au format :
   • nom_utilisateur/répertoire pour des dépôts spécifiques
   • nom_utilisateur/* pour tous les dépôts d’un certain utilisateur

---

Permalink GitHub

Remplacez les liens non permanents de GitHub par des permalinks.

Comment utiliser :

1. Activez github permalinks enabled dans Paramètres → Plugins.

---

Statut en direct des PR

Affichez des indicateurs de statut en direct sur les oneboxes de pull requests GitHub dans les messages et les messages de chat. Le statut se met à jour automatiquement via des webhooks lorsque les PR changent sur GitHub.

Types de Statut

Statut	Couleur	Description
Brouillon	Gris	La PR est marquée comme brouillon
Ouvert	Gris	La PR est ouverte et en attente de révision
Approuvé	Vert	La PR a été approuvée par les réviseurs
Modifications demandées	Orange	Les réviseurs ont demandé des modifications
Fusionné	Violet	La PR a été fusionnée
Fermé	Rouge	La PR a été fermée sans fusion

Comment utiliser :

Étape 1 : Activer la fonctionnalité

Allez dans Admin > Paramètres > Plugins et définissez github pr status enabled sur true.

Étape 2 : Configurer les Jetons d’Accès GitHub

Pour récupérer le statut des PR (en particulier pour les dépôts privés), configurez les jetons d’accès GitHub.

Paramètre : github onebox access tokens

Format :

nom_organisation|ghp_votre_jeton_ici
défaut|ghp_jeton_de_secours_ici

Vous pouvez spécifier des jetons par organisation, ainsi qu’un jeton défaut utilisé comme secours. Chaque ligne doit contenir nom_org|jeton où le jeton est un Jeton d’Accès Personnel (classique) GitHub avec la portée repo.

Exemple :

discourse|ghp_xxxxxxxxxxxxxxxxxxxx
ma-entreprise|ghp_yyyyyyyyyyyyyyyyyyyy
défaut|ghp_zzzzzzzzzzzzzzzzzzzzzz

Étape 3 : Configurer les Webhooks GitHub (pour les mises à jour en temps réel)

Pour obtenir des mises à jour automatiques lorsque les PR changent, configurez un webhook sur GitHub.

Générer un Secret de Webhook :

openssl rand -hex 32

Définissez le paramètre site github webhook secret sur votre secret généré.

Créer le Webhook sur GitHub :

Vous pouvez créer le webhook au niveau de l’organisation (pour couvrir tous les dépôts) ou par dépôt.

Pour une organisation :

1. Allez dans les Paramètres de votre organisation
2. Naviguez vers Webhooks (sous Code, planification et automatisation)
3. Cliquez sur Ajouter un webhook

Pour un dépôt :

1. Allez dans les Paramètres de votre dépôt
2. Naviguez vers Webhooks
3. Cliquez sur Ajouter un webhook

Configuration du Webhook :

Champ	Valeur
URL du payload	https://votre-site-discourse.com/discourse-github/webhooks/github
Type de contenu	application/json
Secret	Votre secret de webhook généré
Vérification SSL	Activer (recommandé)
Événements	Sélectionnez « Me permettre de sélectionner des événements individuels »

Sélectionnez ces événements :

• Pull requests
• Reviews de pull requests

Cliquez sur Ajouter un webhook pour enregistrer.

Étape 4 : Vérifier la configuration

1. Créez un message de test avec une URL de PR GitHub
2. Vérifiez que le onebox s’affiche avec une icône de statut
3. Modifiez le statut de la PR sur GitHub (par exemple, approuvez-la, ou fermez-la)
4. Après quelques secondes, actualisez la page Discourse — le statut devrait se mettre à jour

Vous pouvez vérifier le statut de livraison du webhook dans les paramètres de webhook de GitHub pour confirmer que les événements sont envoyés et reçus avec succès.

Priorité des Statuts

Lorsqu’une PR a plusieurs états (par exemple, approuvée mais avec des modifications également demandées), le statut est déterminé par cette priorité :

1. Fusionné (priorité la plus élevée)
2. Fermé
3. Brouillon
4. Modifications demandées
5. Approuvé
6. Ouvert (par défaut)

Logique du Statut de Révision

La fonctionnalité récupère les informations de révision depuis l’API GitHub pour déterminer le statut d’approbation :

• Prend la dernière révision de chaque réviseur
• Ignore les états de révision « commenté » et « en attente »
• Affiche « modifications demandées » si tout réviseur a demandé des modifications
• Affiche « approuvé » uniquement s’il existe des révisions et qu’aucune ne demande de modifications

Où cela fonctionne

• Messages du forum — Tout message contenant un onebox de PR GitHub
• Messages de chat — Les oneboxes de PR dans le chat affichent également le statut en direct

Remarque : Les oneboxes intégrés (lorsqu’un lien apparaît en ligne dans le texte plutôt que comme un aperçu complet) n’affichent pas d’icônes de statut.

Migration depuis le Composant de Thème GitHub Status

Cette fonctionnalité remplace le composant de thème GitHub Status Indicators. Les deux ne sont pas compatibles et ne doivent pas être utilisés ensemble.

Si vous utilisez actuellement le composant de thème :

1. Désactivez et supprimez le composant de thème github-status-theme
2. Activez cette fonctionnalité intégrée via le paramètre github pr status enabled

---

Configuration

Jeton d’Accès GitHub

Pour que la fonctionnalité de linkback fonctionne et que les badges soient accordés à vos utilisateurs, vous devez fournir un jeton d’accès GitHub. Vous pouvez générer votre jeton ici : Sign in to GitHub · GitHub.

La fonctionnalité de linkback nécessite la portée public_repo, et l’attribution des badges ne nécessite aucune portée (laissez tout décoché si vous voulez uniquement des badges). Puisque la portée public_repo accorde un accès en écriture aux dépôts, nous vous recommandons de créer un compte GitHub jetable qui n’a accès à aucun dépôt et de l’utiliser uniquement pour générer un jeton.

Portées de Jeton par Fonctionnalité

Fonctionnalité	Portée Requise
Badges	Aucune portée requise
Linkback	public_repo
Statut PR (dépôts publics)	Aucune portée requise
Statut PR (dépôts privés)	repo

---

Référence des Paramètres Site

Paramètre	Défaut	Description
enable discourse github plugin	false	Interrupteur principal pour le plugin
github badges enabled	false	Activer les badges de contribution GitHub
github badges repos	(vide)	URL des dépôts à suivre pour les badges
github linkback enabled	false	Activer les linkbacks de GitHub vers Discourse
github linkback access token	(vide)	Jeton d’accès pour la fonctionnalité de linkback
github linkback projects	(vide)	Projets pour lesquels créer des linkbacks
github permalinks enabled	false	Remplacer les liens GitHub par des permalinks
github pr status enabled	false	Activer les icônes de statut PR sur les oneboxes
github webhook secret	(vide)	Secret pour la vérification de signature de webhook
github onebox access tokens	(vide)	Jetons d’accès pour l’API GitHub (format : org|jeton)

---

Détails Techniques

Utilisation de l’API de Statut PR

Lorsqu’un onebox de PR GitHub est généré, Discourse effectue jusqu’à deux appels API :

1. Données PR : GET /repos/{owner}/{repo}/pulls/{number} — Récupère les informations de base de la PR, y compris l’état, le statut de fusion et le statut de brouillon
2. Révisions : GET /repos/{owner}/{repo}/pulls/{number}/reviews — Récupère les données de révision pour déterminer le statut d’approbation

Ces appels utilisent votre jeton d’accès configuré si disponible, permettant l’accès aux dépôts privés.

Sécurité des Webhooks

Les requêtes de webhook sont vérifiées à l’aide de la validation de signature HMAC-SHA256. GitHub signe le payload du webhook avec votre secret, et Discourse vérifie cette signature avant de traiter. Les signatures invalides sont rejetées avec une réponse 403.

Événements de Webhook qui Déclenchent des Mises à Jour

• Changements d’état de la PR (ouverte, fermée, rouverte)
• PR fusionnée
• Changements de statut de brouillon (converti en brouillon, prêt pour révision)
• Reviews de pull requests soumises
• Reviews éditées ou supprimées

Considérations de Performance

• Le rebaking est mis en file d’attente en tant que tâche de fond de faible priorité pour éviter d’impacter les performances du site
• Seuls les messages/messages avec des oneboxes complets de PR GitHub sont rebakés (les oneboxes intégrés sont ignorés)
• Les rebakes de messages de chat ignorent les notifications pour éviter les alertes en double

---

JOURNAL DES MODIFICATIONS

2025-12-10

• CORRECTION : Ignorer les notifications lors du rebake des messages de chat provenant de webhooks GitHub

2025-12-09

• CORRECTION : Ignorer le rebake des messages avec des oneboxes intégrés de PR GitHub
• CORRECTION : Éviter l’état intermédiaire lors du rebake des messages avec des oneboxes
• CORRECTION : Rebacker les messages de chat lorsque le statut de la PR GitHub change
• UX : Utiliser min-height pour éviter les changements de mise en page lorsque l’icône de statut change
• UX : Réduire la taille de l’icône de statut de PR GitHub sur mobile

2025-12-08

• FONCTIONNALITÉ : Ajouter le statut « modifications demandées » aux oneboxes de PR GitHub

2025-12-04

• FONCTIONNALITÉ : Icône de statut en direct de PR GitHub

2025-11-10

• FONCTIONNALITÉ : Liste d’autorisation et liste d’interdiction pour les linkbacks

2025-11-08

• FONCTIONNALITÉ : Ajouter une liste d’ignorance de catégorie pour les linkbacks GitHub

2024-12-20

• DEV : Déplacer discourse-github vers le noyau (n’exige plus d’installation séparée)

[ImmaZoni (Justin)]

Quel est le processus pour plusieurs liens ? Est-ce qu’ils sont simplement ajoutés au même commentaire de commit ? Ou est-ce qu’un nouveau commentaire est créé à chaque fois ?

[satonotdead]

Je me demande si les badges de commits et de PRs pourraient être simplifiés car nous essayons de nous éloigner du paradoxe du choix :)\n\nActuellement, je viens de forker et de supprimer les badges de commit mais bien sûr, je me perds du badge de commit (car je commite directement) et le fork n’est pas égal à rester toujours avec le cœur.

[xomiamoore (Mia)]

@Discourse

• username/repository pour des dépôts spécifiques
• username/* pour tous les dépôts d’un certain utilisateur

Le caractère générique * n’a pas fonctionné pour moi pour une organisation GitHub, j’ai fini par tout mettre dans chaque dépôt individuellement. D’autres ont-ils eu des problèmes avec cela pour une organisation par rapport à un utilisateur ?

[greyli]

Comment définir la langue du commentaire de renvoi ?

[cultiv (Sebastiaan Janssen)]

Merci, j’aime beaucoup ce plugin ! J’étais confus au sujet du système de badges et j’étais content de trouver l’explication dans un autre sujet : Github Badges are not working. Its hard to see if I do something wrong or if the plugin is not working - #4 by simon

Cependant, cette réponse note que

Le plugin crée 6 badges :

Je ne vois aucun de ces badges, je ne sais pas ce qui s’est passé ? Y a-t-il un moyen de (re)déclencher la création de ces badges ?

[cultiv (Sebastiaan Janssen)]

Pour répondre à ma propre question, après quelques heures, la tâche planifiée s’est exécutée et c’est à ce moment-là que les badges ont été créés.

@cultiv

Y a-t-il un moyen de (re)déclencher la création de ces badges ?

La méthode manuelle pour ce faire serait de déclencher le job sidekiq semble-t-il.

[tomtjes (Thomas Reintjes)]

Demande de fonctionnalité : exclure les catégories et/ou tags des backlinks

Nous avons une catégorie Annonces dans laquelle le plugin RSS extrait automatiquement les nouvelles versions de GitHub. Lorsque les notes de version contiennent des liens vers des issues, ces liens apparaissent également dans Discourse et un backlink est créé, mais il n’est pas utile pour personne, ce qui crée du désordre sur Github.

Je voudrais pouvoir exclure certains posts, c’est-à-dire des catégories ou tags, ou même simplement des posts d’un utilisateur configuré dans le plugin RSS, afin qu’ils ne créent pas de backlinks.

[david (David Taylor)]

Ce plugin est maintenant inclus dans le cœur de Discourse dans le cadre de Bundling more popular plugins with Discourse core. Si vous auto-hébergez et utilisez le plugin, vous devez le supprimer de votre app.yml avant votre prochaine mise à niveau.