Valider une fonctionnalité
Les merge requests d’une même issue, regroupées sur tous les projets, validées et fusionnées ensemble vers la principale.
Vérifié dans l’application le 5 septembre 2026
Une fonctionnalité touche trois dépôts : trois merge requests, trois onglets GitLab pour vérifier que chacune est fusionnable, et le risque d’en fusionner deux sur trois. L’écran Fonctionnalités regroupe les merge requests ouvertes vers la branche principale par issue, dit pour chaque issue si tout est prêt, et les fusionne ensemble en un geste. C’est l’écran du product owner : on l’ouvre au fil de l’eau, souvent pour ne rien faire.
Qui peut Product ownerDéveloppeurManagerAdministrateur
Tout le monde lit la liste et le détail. Valider une issue, c’est-à-dire fusionner ses merge requests, demande le rôle de product owner au moins. Un développeur valide aussi : le verrou qui compte est dans GitLab (approbations, protections de branche), pas dans Deployer.
Lire la liste
Les issues sont groupées par board, le projet GitLab qui porte les tickets, une section par board quand il y en a plusieurs. Dans chaque section, les prêtes en tête, puis les partielles, puis celles en attente ; l’en-tête de section compte les prêtes (« Infra / Socle · 1 prête »).
Une carte d’issue porte le numéro, le nombre de merge requests, l’état agrégé à droite, le titre avec ses étiquettes GitLab, et un chip par projet touché, coloré selon l’état de sa merge request : vert prêt, ambre bloqué, neutre pas encore lu.
| État | Ce qui le caractérise |
|---|---|
| prête | Toutes ses merge requests sont fusionnables. Le seul état actionnable. |
| 2/3 | Au moins une bloque. Le chiffre dit combien il en reste ; le panneau dit laquelle et pourquoi. |
| en attente | Au moins une est transitoire (GitLab calcule, pipeline en cours), aucune ne bloque. Ce n’est pas un défaut. |
- Filtrer par le rail
Sept axes, tous en cases à cocher : Boards, État, Ce qui bloque (conflit, approbations manquantes, discussions ouvertes, pipeline en échec, brouillon), Créateur, Assignés, Labels GitLab, Dépôt de code. OU dans un axe, ET entre axes ; seuls les Labels GitLab se combinent en ET, comme dans GitLab. Chaque valeur affiche ce que donnerait sa coche. « Non assignée » est épinglée en tête des assignés ; « moi » coche votre compte GitLab rattaché.
- Chercher
La recherche de la barre porte sur la référence, le titre, le nom de projet et le numéro de merge request. Elle se combine avec le rail. « Réinitialiser » efface tout. Les filtres vivent dans l’URL : un lien partagé pendant une revue ouvre la même lecture.
- Régler l'affichage
Deux réglages de densité, retenus d’une session à l’autre : « Étiquettes sur les cartes » et « Projets sur les cartes ». Sur un espace qui n’étiquette pas ses issues ce sont les projets qui encombrent, sur un espace à un seul dépôt ce sont les étiquettes.
Une issue sélectionnée, les flèches haut et bas passent à la précédente et à la suivante. La sélection survit à un rafraîchissement et à un changement de filtre : le panneau rappelle toujours le board de l’issue ouverte.
Le panneau : la fonctionnalité, puis la mécanique
Le panneau se lit de haut en bas dans l’ordre des décisions : ce que c’est, est-ce fini, le geste, et seulement ensuite par quoi ça passe.
- Ce que c’est : le board en badge, la référence complète (lien vers l’issue GitLab), le titre, la description rendue comme dans GitLab et tronquée avec « voir plus », l’auteur et les assignés (à qui demander), la date d’ouverture et la dernière activité. Une issue sans activité depuis trois semaines le dit franchement : c’est souvent l’information la plus utile.
- Est-ce fini : une ligne en langage de product owner. « Prête à valider, 3 merge requests, 3 projets ». Ou « 2 sur 3 sont prêtes, frontend attend une approbation ». Ou « En attente, GitLab calcule encore l’état de cette issue ».
- Le geste : le bouton « Fusionner les 3 merge requests vers la principale », désactivé tant que l’issue n’est pas prête, la ligne du dessus disant pourquoi. Sous le bouton, au nom de qui la fusion se fera.
- Les merge requests : une ligne par projet, repliée, avec son numéro (lien vers GitLab) et sa pastille. Ce qui bloque est déplié d’office ; ce qui est prêt reste replié.
| Ce que GitLab dit | Ce que la ligne affiche | Qui lève le blocage |
|---|---|---|
| mergeable | prête | personne, c’est bon |
| draft_status | brouillon | l’auteur, qui doit la sortir de brouillon |
| not_approved | approbations manquantes | les approbateurs, dans GitLab |
| ci_must_pass | le pipeline a échoué | l’auteur, avec le lien vers le pipeline |
| ci_still_running | pipeline en cours | personne, on relira |
| discussions_not_resolved | discussions ouvertes | les participants, dans GitLab |
| conflict, need_rebase | conflit avec la cible | l’auteur, par un rebase dans GitLab |
| blocked_status | bloquée par une autre merge request | fusionner l’autre d’abord |
| checking, unchecked | GitLab calcule | personne, on relira |
Le statut brut de GitLab reste affiché sous la formulation lisible : c’est le terme exact à chercher dans l’interface GitLab.
Valider
- Fusionner
Le bouton ouvre une confirmation qui liste les merge requests par numéro et projet. C’est irréversible et ça touche plusieurs dépôts. Seul le pipeline de la principale partira : fusionner vers la principale ne met rien en service.
- Au nom de qui
Avec votre compte GitLab rattaché, la fusion porte votre nom et vos droits : une branche protégée peut vous être refusée. Sans compte rattaché, l’espace peut autoriser le repli sur le compte du token, et le panneau le dit, parce que le bot contourne souvent les approbations affichées juste au-dessus. Sans rattachement ni repli, le bouton renvoie vers « Mon compte GitLab ».
- Après
Toutes fusionnées : l’issue quitte la liste, et un message le dit. Fusion partielle : ce qui est fusionné le reste, les refus portent leur motif brut, et rejouer ne reprend que ce qui manque. Un refus « pipeline en cours » n’est pas une panne : réessayez dans quelques minutes. Un refus « la branche a bougé » est une protection : quelqu’un a poussé depuis la lecture, relisez.
Deployer ne ferme pas l’issue : GitLab le fait si les merge requests portent « Closes ». Ce qui est fusionné se relit ensuite dans les notes de version.
Le chargement et la fraîcheur
Lire toutes les merge requests ouvertes de seize dépôts coûte près de cent appels GitLab et peut prendre une minute. L’écran d’attente montre la phase et l’avancement : la lecture des projets, cochés un à un ; l’analyse des merge requests (retrouver l’issue de chacune) ; la lecture des issues. La liste s’affiche ensuite d’un coup, toutes les issues en attente, puis les verdicts arrivent par lots ; un liseré sous la barre d’écran en montre la progression, et le rail signale que les comptes d’État et de Ce qui bloque bougent encore.
Quand l’espace a activé le module Assemblage, chaque carte porte une pastille de plus : embarquée ou écartée de la branche assemblée, et le panneau renvoie vers le candidat dans l’écran Assemblage.