Intégration GitHub

Une fois GitHub connecté, Multica associe automatiquement les pull requests à partir des identifiants de tâche. Le détail de la tâche affiche directement l'état de la PR, l'ampleur des modifications, les résultats de la CI et les conflits de fusion.

L'intégration GitHub se contente de lire les dépôts autorisés lors de l'installation ; elle ne pousse jamais de commits, de commentaires ni de status checks.

Multica auto-hébergé peut aussi connecter en parallèle des instances Forgejo, Gitea ou GitLab auto-hébergées, avec la même association automatique des PR, le même changement de statut à la fusion et le même affichage de la CI. Le point d'entrée est Paramètres → Code ; voir Fournisseurs Git auto-hébergés. Multica Cloud ne propose pas ce point d'entrée.

Connecter GitHubCopy Anchor Link

Un propriétaire ou un administrateur de l'espace de travail peut effectuer la connexion :

L'état de la connexion s'affiche sur la même page. Les membres ordinaires peuvent consulter cet état, mais ne peuvent ni connecter, ni déconnecter, ni modifier les interrupteurs.

Interrupteurs de fonctionsCopy Anchor Link

La section Pull requests et tâches de Paramètres → Code comporte ces réglages. Mettre en pause les fonctionnalités GitHub, dans le menu ⋯ de la ligne GitHub, arrête les trois interrupteurs ci-dessous sans déconnecter la GitHub App.

Après la fusion des PR, passer la tâche à s'applique à tous les hébergeurs de code, y compris les fournisseurs Git auto-hébergés.

Associer une PR à une tâcheCopy Anchor Link

Le plus simple est de mettre l'identifiant de la tâche dans le nom de branche ou le titre de la PR. Par exemple, pour la tâche MUL-123 :

mul-123-fix-login-redirect

MUL-123 Fix the redirect after login

Multica ignore la casse et ne reconnaît que le préfixe de tâche de l'espace de travail courant. Une même PR peut être associée à plusieurs tâches.

Si l'identifiant n'apparaît que dans la description de la PR, placez-le juste après un mot-clé de clôture :

Closes MUL-123
Fixes MUL-123
Resolves MUL-123

Une simple mention dans la description, comme Related to MUL-123, n'associe pas du tout la PR à cette tâche. Les messages de commit et les commentaires de PR ne déclenchent pas non plus l'association.

Vous pouvez aussi associer une PR à la main : dans le bloc Pull requests de la tâche, cliquez sur + et collez l'URL de la PR. Pour retirer une PR d'une tâche, ouvrez le menu ⋯ de sa ligne et choisissez Retirer de la tâche ; Multica ne la réassociera plus à partir de son titre ou de sa branche.

Voir les PR d'une tâcheCopy Anchor Link

Une fois associées, les PR apparaissent dans le bloc Pull requests du détail de la tâche. Chaque entrée affiche :

• le dépôt, le numéro, le titre et l'auteur ;
• l'état Ouverte, Brouillon, Fusionnée ou Fermée ;
• le nombre de lignes ajoutées et supprimées, et le nombre de fichiers modifiés ;
• le statut CI : toutes les vérifications ont réussi (avec leur nombre), certaines sont en échec (avec le nom des vérifications concernées) ou certaines sont en cours ; les PR sans vérification configurée n'affichent pas cet élément, et « aucune vérification » n'est jamais considéré comme une réussite ;
• la possibilité de fusion : « Prête à fusionner » (uniquement lorsque GitHub signale un état de fusion propre), « Conflits de fusion », « Bloquée » ou « En retard sur la base ».

Le statut CI et la possibilité de fusion proviennent d'instantanés que Multica récupère depuis l'API GitHub, et les deux sont indépendants ; les PR fusionnées ou fermées n'affichent plus ni l'un ni l'autre. Lorsque GitHub est momentanément indisponible, la carte conserve le dernier instantané et le signale comme périmé.

Sous la liste, une ligne indique ce qui va se passer : par exemple Passe à Terminé quand #19 est fusionnée, ou quelle PR a été fermée sans fusion. Cette ligne n'apparaît pas lorsque l'espace de travail ne change pas le statut ou que la tâche a déjà le statut cible.

Cliquez sur une entrée pour ouvrir la PR sur GitHub. Désactiver la Barre latérale des pull requests masque seulement ce bloc ; cela ne déconnecte rien.

Quand des PR fusionnées changent le statut d'une tâcheCopy Anchor Link

Une PR fusionnée ne signifie pas forcément que la tâche est terminée : c'est donc l'espace de travail qui décide de l'effet d'une fusion, dans Paramètres → Code → Après la fusion des PR, passer la tâche à. Choisissez Done (la valeur par défaut des nouveaux espaces de travail), un autre statut de type démarré ou terminé (un statut personnalisé comme En attente de recette convient aussi), ou Ne pas changer. Les espaces de travail qui existaient avant ce réglage conservent leur comportement : si la fusion ne terminait pas toujours leurs tâches, ils démarrent sur Ne pas changer.

Une tâche passe au statut choisi lorsque toutes les conditions suivantes sont réunies :

1. toutes les PR associées sont Merged : une PR Open ou Draft fait attendre la tâche, tout comme une PR fermée sans fusion tant que vous ne l'avez pas retirée de la tâche ;
2. la tâche n'est pas done ou cancelled, n'est pas en Triage, n'a pas déjà le statut cible et n'a pas été exclue pour elle seule (Pull requests → ⋯ → Garder le statut à la fusion des PR).

La façon dont une PR a été associée ne change rien : le titre, le nom de branche et un Closes MUL-123 dans la description ne font que l'associer. Quand une PR ne livre qu'une partie de la tâche, ou qu'une mise en production ou une vérification doit suivre la fusion, gardez le statut de cette tâche depuis son menu Pull requests.

La vérification a lieu lorsqu'un événement de PR touche la tâche : une PR associée est fusionnée, une PR est associée, ou une association est retirée. Rouvrir une tâche ne la fait pas repasser au statut cible ; c'est la prochaine PR associée fusionnée qui le fait. Modifier le réglage ne change pas les tâches dont les PR ont été fusionnées auparavant.

Le changement de statut est inscrit dans la chronologie comme une action système qui nomme les PR, et les membres abonnés à la tâche sont notifiés.

Plusieurs espaces de travailCopy Anchor Link

Une même installation de la GitHub App peut être connectée à plusieurs espaces de travail Multica. Les événements GitHub parviennent à chaque espace de travail séparément et sont comparés au préfixe de tâche propre à chacun.

Par exemple, une PR qui référence à la fois MUL-1 et ENG-2 peut être associée dans deux espaces de travail aux préfixes différents. Les espaces de travail ne voient jamais les tâches les uns des autres.

Si un même identifiant correspond à une tâche dans plusieurs des espaces de travail connectés (possible lorsqu'ils partagent un préfixe), Multica ne l'associe automatiquement dans aucun d'eux, afin que la fusion de la PR ne termine pas une tâche sans rapport. Associez la PR à la main dans le bon espace de travail.

DéconnecterCopy Anchor Link

Choisir Déconnecter dans le menu ⋯ de la ligne GitHub, sur Paramètres → Code, supprime seulement la relation entre l'espace de travail Multica courant et l'installation ; cela ne désinstalle pas l'App de GitHub à votre place. Les enregistrements de PR existants sont conservés, et les nouveaux événements cessent d'arriver dans cet espace de travail.

Pour révoquer l'autorisation d'accès aux dépôts côté GitHub, désinstallez l'App ou ajustez son périmètre de dépôts depuis la page des installations de GitHub Apps de votre compte personnel ou de votre organisation. Après la désinstallation, tous les espaces de travail Multica liés à cette installation cessent de recevoir des événements.

Configuration en auto-hébergementCopy Anchor Link

Multica Cloud n'a pas besoin de cette section. En auto-hébergement, vous devez d'abord créer votre propre GitHub App.

GITHUB_APP_SLUG=multica-acme
GITHUB_WEBHOOK_SECRET=<the webhook secret you entered when creating the App>
FRONTEND_ORIGIN=https://multica.example.com

GITHUB_APP_ID=<the GitHub App's numeric ID>
GITHUB_APP_PRIVATE_KEY=<full PEM private key, keeping the BEGIN/END lines and newlines>

make migrate-up

DépannageCopy Anchor Link

• Bouton de connexion désactivé : vérifiez que GITHUB_APP_SLUG et GITHUB_WEBHOOK_SECRET parviennent bien au processus de l'API.
• Le webhook renvoie 401 : vérifiez que la GitHub App et l'API utilisent le même secret de webhook, puis relancez la livraison depuis Recent Deliveries sur GitHub.
• PR non associée : vérifiez que le dépôt fait partie du périmètre autorisé de l'App, que l'association automatique est activée, que l'identifiant appartient à l'espace de travail courant et que personne n'a retiré la PR de la tâche.
• Identifiant dans la description, mais PR non associée : placez-le juste après un mot-clé de clôture (Closes MUL-123), ou dans le nom de branche ou le titre de la PR, ou associez la PR à la main.
• Aucun statut CI : vérifiez que GITHUB_APP_ID et GITHUB_APP_PRIVATE_KEY sont configurées, et que l'App dispose des permissions Pull requests, Checks et Commit statuses en lecture seule, avec les événements correspondants souscrits. La permission Contents n'est pas nécessaire. Après l'ajout de permissions à une App déjà installée, le propriétaire de chaque installation doit les approuver sur GitHub pour qu'elles prennent effet.
• Statut de la tâche inchangé après la fusion de la PR : lisez la ligne sous la liste Pull requests de la tâche. Elle nomme les PR encore ouvertes ou fermées sans fusion, ou indique que la tâche garde son statut à la fusion des PR. Si aucune ligne n'apparaît, le réglage de l'espace de travail est Ne pas changer, ou la tâche a déjà le statut cible.

Étapes suivantesCopy Anchor Link

• Tâches — le lien entre les transitions de statut et les PR fusionnées.
• Ressources de projet — les dépôts utilisés par les agents lors des exécutions.
• Variables d'environnement — la configuration complète de la GitHub App en auto-hébergement.