2017-09-27 2 views
0

Notre cycle de développement gère plusieurs branches de version simultanées.Fusionner avant construction L'option Jenkins git plugin ne se déclenche pas

Nous voulons avoir un moyen fiable d'exposer les conflits de fusion dans les branches de publication le plus tôt possible dans le cycle. Dans nos travaux de build dans Jenkins, nous spécifions un glob de release * comme branche à construire, et spécifions l'option git plugin à "Merge Before Build" à maîtriser avant le début de la génération.

Mon attente ici est que le plugin fusionnerait toutes les branches de publication qu'il trouve dans le maître avant de commencer la construction de chaque branche de publication.

J'ai mis en place un repo factice pour le tester. Le repo a un fichier texte. Il y a 3 branches:

maître (principal) RELEASE1 (prise du maître) release2 (pris du maître)

mettre à jour la même ligne dans le fichier dans RELEASE1 et release2 pour créer délibérément un conflit de fusion qui J'ai confirmé existe.

Maintenant, quand je construis le travail, je m'attendrais à ce que Jenkins essaie de fusionner release1 et release2 en master, où il rencontrerait le conflit de fusion et échouerait, ce que nous voulons. Cependant, Jenkins ne semble pas tenter cela, bien que l'option "Merge Before Build" soit définie.

Fetching upstream changes from [email protected]:xxxxxxx/test_repo.git 
> git --version # timeout=10 
> git fetch --tags --progress [email protected]:xxxxxxx/test_repo.git 
+refs/heads/*:refs/remotes/origin/* 
Seen branch in repository origin/master 
Seen branch in repository origin/release1 
Seen branch in repository origin/release2 
Seen 3 remote branches 
Checking out Revision 5b75c954f334a2fc6c683cd7304d4d84826f02cd 
(origin/release2, origin/master) 
> git config core.sparsecheckout # timeout=10 
> git checkout -f 5b75c954f334a2fc6c683cd7304d4d84826f02cd 
> git rev-list 5b75c954f334a2fc6c683cd7304d4d84826f02cd # timeout=10 
> git rev-list 5b75c954f334a2fc6c683cd7304d4d84826f02cd # timeout=10 
Set build name. 
New build name is '#8 ' 
[build-sharknado-app] $ /bin/sh -xe /tmp/hudson1678313403112351764.sh 
+ cat file.txt 
x=7 

Les travaux aboutissent et nous ne voyons pas le conflit de fusion.

Pourquoi la fusion de plusieurs branches de release * vers master ne se produit-elle pas?

+0

'git checkout -f 5b75c954f334a2fc6c683cd7304d4d84826f02cd'. Un commit spécifique est extrait de sorte qu'il soit dans un état HEAD détaché. La branche 'master' n'est pas extraite et n'existe donc pas localement, bien que' origin/master' pointe vers '5b75c954f334a2fc6c683cd7304d4d84826f02cd'. Cela peut être la cause. – ElpieKay

+0

Cela semble être le problème, mais je ne sais pas pourquoi un commit est en cours d'extraction. Je spécifie "origin/release *" comme l'option "Branches à construire", et ces branches existent. Toutefois, seule la version 2 est fusionnée avec master dans le cadre de la génération. –

Répondre

0

Dans ce cas, le plugin Git agit comme prévu.

Toutes les branches sont analysées pour les changements de révision (sur la base de la copie locale du repo git dans l'espace de travail Jenkins). Quand aucun n'est trouvé, Jenkins n'agit que sur le commit le plus récent.

Le plugin Git n'est pas conçu pour fusionner plusieurs branches à maîtriser dans la même construction.

Lorsque des modifications sont détectées sur plusieurs branches, Jenkins lance un nouveau travail de construction pour chaque branche. Dans chaque travail, la branche concernée est fusionnée avec le maître, mais Jenkins extrait le maître avec l'option -f, ce qui réinitialise le HEAD sur le maître, de sorte qu'un conflit de construction résultant de la fusion de plusieurs branches au maître n'est pas détecté. Cela signifie que Jenkins ne peut détecter qu'un conflit de fusion résultant de la fusion d'une branche à une autre, et non un conflit résultant de la fusion de deux branches différentes vers la même branche de destination.