doc-locale/fr-fr/ci/pipelines/merge_trains.md
{{< details >}}
{{< /details >}}
Dans les projets avec des fusions fréquentes vers la branche par défaut, les modifications apportées dans différentes merge requests peuvent entrer en conflit les unes avec les autres. Utilisez les merge trains pour placer les merge requests dans une file d'attente. Chaque merge request est comparée aux autres merge requests antérieures pour s'assurer qu'elles fonctionnent toutes ensemble.
Pour plus d'informations sur :
Un merge train démarre lorsqu'aucune merge request n'est en attente de fusion et que vous sélectionnez Fusionner ou Configurer la fusion automatique. GitLab lance un pipeline de merge train qui vérifie que les modifications peuvent être fusionnées dans la branche par défaut. Ce premier pipeline est identique à un pipeline de résultats fusionnés, qui s'exécute sur les modifications des branches source et cible combinées. L'auteur du commit de résultat fusionné interne est l'utilisateur qui a initié la fusion.
Pour mettre en file d'attente une deuxième merge request afin qu'elle fusionne immédiatement après la fin du premier pipeline, sélectionnez Fusionner ou Configurer la fusion automatique pour l'ajouter au train. Ce deuxième pipeline de merge train s'exécute sur les modifications des deux merge requests combinées avec la branche cible. De même, si vous ajoutez une troisième merge request, ce pipeline s'exécute sur les modifications des trois merge requests fusionnées avec la branche cible. Les pipelines s'exécutent tous en parallèle.
Chaque merge request fusionne dans la branche cible uniquement après :
Si un pipeline de merge train échoue, la merge request n'est pas fusionnée. GitLab supprime cette merge request du merge train et lance de nouveaux pipelines pour toutes les merge requests qui étaient mises en file d'attente après elle.
Par exemple :
Trois merge requests (A, B et C) sont ajoutées à un merge train dans l'ordre, ce qui crée trois pipelines de résultats fusionnés qui s'exécutent en parallèle :
A combinées avec la branche cible.A et B combinées avec la branche cible.A, B et C combinées avec la branche cible.Si le pipeline pour B échoue :
A) continue de s'exécuter.B est supprimée du train.C est annulé, et un nouveau pipeline démarre pour les modifications de A et C combinées avec la branche cible (sans les modifications de B).Si A se termine avec succès, elle fusionne dans la branche cible, et C continue de s'exécuter. Toutes les nouvelles merge requests ajoutées au train incluent les modifications de A désormais dans la branche cible, et les modifications de C provenant du merge train.
<i class="fa-youtube-play" aria-hidden="true"></i> Regardez cette vidéo pour une démonstration sur comment l'exécution parallèle des merge trains peut empêcher les commits de casser la branche par défaut.
GitLab CI/CD détecte les pipelines redondants et les annule pour économiser des ressources.
Les pipelines de merge train redondants se produisent lorsque :
Dans ces cas, GitLab doit créer de nouveaux pipelines de merge train pour certaines ou toutes les merge requests du train. Les anciens pipelines comparaient les modifications combinées précédentes dans le merge train, qui ne sont plus valides, et ces anciens pipelines sont donc annulés.
Prérequis :
Pour activer les merge trains :
Prérequis :
Pour démarrer un merge train :
Le statut du merge train de la merge request s'affiche sous le widget du pipeline avec un message similaire à A new merge train has started and this merge request is the first of the queue. View merge train details. Vous pouvez sélectionner le lien pour afficher le merge train.
D'autres merge requests peuvent maintenant être ajoutées au train.
{{< history >}}
{{< /history >}}
Vous pouvez afficher le merge train pour obtenir une meilleure visibilité sur l'ordre et le statut des merge requests dans la file d'attente. La page de détails du merge train affiche les merge requests actives dans la file d'attente et les merge requests fusionnées qui faisaient partie du train.
Pour accéder aux détails du merge train depuis la liste des merge requests :
Vous pouvez également accéder à cette vue en sélectionnant Voir les détails du train de fusion depuis :
Vous pouvez également supprimer ({{< icon name="close" >}}) une merge request depuis la vue des détails du merge train.
{{< history >}}
merge_when_checks_pass_merge_train. Désactivée par défaut. Désactivé par défaut.merge_when_checks_pass_merge_train a été supprimé.{{< /history >}}
Prérequis :
Pour ajouter une merge request à un merge train :
Le statut du merge train de la merge request s'affiche sous le widget du pipeline avec un message similaire à This merge request is 2 of 3 in queue.
Chaque merge train peut exécuter un nombre maximum de pipelines en parallèle. La limite par défaut est de 20. Si vous ajoutez au merge train plus de merge requests que la limite autorisée, les merge requests supplémentaires sont mises en file d'attente jusqu'à ce qu'un pipeline se termine. Le nombre de merge requests en file d'attente est illimité.
Lorsque vous supprimez une merge request d'un merge train :
Vous pouvez ajouter de nouveau la merge request à un merge train ultérieurement.
Pour supprimer une merge request d'un merge train :
Si vous avez une merge request prioritaire, comme un correctif critique qui doit être fusionné d'urgence, vous pouvez sélectionner Fusionner immédiatement.
[!warning] La fusion immédiate peut utiliser beaucoup de ressources CI/CD. N'utilisez cette option que dans les situations critiques.
Lorsque vous fusionnez une merge request immédiatement :
[!note] L'option merge immediately peut ne pas être disponible si votre projet utilise la méthode de fusion fast-forward et que la branche source est en retard par rapport à la branche cible. Consultez le ticket 434070 pour plus de détails.
{{< details >}}
{{< /details >}}
{{< history >}}
merge_trains_skip_train. Désactivé par défaut.{{< /history >}}
[!flag] Sur GitLab Self-Managed, cette fonctionnalité est disponible par défaut. Pour masquer la fonctionnalité, un administrateur peut désactiver le feature flag nommé
merge_trains_skip_train. Sur GitLab.com et GitLab Dedicated, cette fonctionnalité est disponible.
Vous pouvez autoriser la fusion des merge requests sans redémarrer complètement un merge train en cours d'exécution. Utilisez cette fonctionnalité pour fusionner rapidement des modifications qui peuvent ignorer le pipeline en toute sécurité, par exemple des mises à jour mineures de documentation.
Vous ne pouvez pas ignorer les merge trains pour les méthodes de fusion fast-forward ou semi-linéaire. Pour plus d'informations, consultez le ticket 429009.
L'ignorance des merge trains est une fonctionnalité expérimentale. Elle peut être modifiée ou entièrement supprimée dans les futures versions de release.
[!warning] Vous pouvez utiliser cette fonctionnalité pour fusionner rapidement des correctifs de sécurité ou des correctifs de bugs, mais les modifications de la merge request qui a ignoré le train ne sont pas vérifiées par rapport aux autres merge requests du train. Si ces autres pipelines de merge train se terminent avec succès et fusionnent, il existe un risque que les modifications combinées soient incompatibles. La branche cible pourrait alors nécessiter un travail supplémentaire pour résoudre les nouveaux échecs.
Prérequis :
Pour activer l'ignorance du train sans redémarrage de pipeline :
Pour fusionner une merge request en ignorant le merge train, utilisez le point de terminaison de l'API de fusion des merge requests pour fusionner avec l'attribut skip_merge_train défini sur true.
La merge request fusionne, et les pipelines de merge train existants ne sont pas annulés ni redémarrés.
{{< history >}}
{{< /history >}}
Par défaut, chaque merge train peut exécuter un maximum de 20 pipelines en parallèle. Lorsque cette limite est atteinte, les merge requests supplémentaires sont mises en file d'attente jusqu'à ce qu'un emplacement de pipeline soit disponible.
Pour modifier cette limite pour votre projet :
1. Une valeur de 1 traite les merge requests séquentiellement sans parallélisme.La limite du projet ne peut pas dépasser la limite de l'instance.
Vous pouvez également utiliser l'API des projets, ou l'API GraphQL.
Si une merge request devient impossible à fusionner pendant l'exécution d'un pipeline de merge train, le merge train retire automatiquement votre merge request. Les causes courantes incluent :
Vous pouvez trouver la raison pour laquelle la merge request a été retirée du merge train dans les notes système. Vérifiez la section Activité dans l'onglet Vue d'ensemble pour trouver un message similaire à : User removed this merge request from the merge train because ...
Vous ne pouvez pas utiliser la fusion automatique (anciennement Fusionner lorsque le pipeline réussit) pour ignorer le merge train lorsque les merge trains sont activés. Consultez le ticket 12267 pour plus d'informations.
Lorsqu'un pipeline de merge train échoue, la merge request est retirée du train et le pipeline ne peut pas être réessayé après son échec. Les pipelines de merge train s'exécutent sur le résultat fusionné des modifications de la merge request et des modifications des autres merge requests déjà présentes dans le train. Si la merge request est retirée du train, le résultat fusionné est obsolète et le pipeline ne peut pas être réessayé.
Vous pouvez :
retry au job s'il échoue de manière intermittente. S'il réussit après une nouvelle tentative, la merge request n'est pas supprimée du merge train.Lorsque Les pipelines doivent réussir est activé, mais que le dernier pipeline a échoué :
The pipeline for this merge request failed. Please retry the job or push a new commit to fix the failure.Avant de pouvoir rajouter une merge request à un merge train, vous pouvez essayer de :
Consultez le ticket associé pour plus d'informations.