2011-07-24 3 views
9

Notre équipe utilise jenkins et git. Nous cherchons à implémenter la fonctionnalité avancée du plugin git qui permet des préconstructions avant de pousser les validations vers le référentiel béni. Voir https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-AdvancedFeaturesgit jenkins fonctionnalité avancée

Cependant, j'ai de la difficulté à comprendre l'ensemble du processus.

Voici un extrait:

Configurer votre projet Jenkins, et laissez le champ « branche » dans le vide SCM Git. Cela amènera Jenkins à considérer n'importe quel changement sur n'importe quelle branche pour la construction.

Ensuite, sélectionnez un nom de branche particulier en tant que cible d'intégration dans la section "Avancé" (par exemple, "maître" ou "stable"), puis sélectionnez "Fusionner avant la génération".

Sélectionnez 'Réinitialiser les balises GIT dans le référentiel d'origine' à partir des actions de post-construction (cela est nécessaire pour mettre à jour votre référentiel git centralisé avec les résultats de la construction). Maintenant, les développeurs ne devraient jamais s'engager directement dans votre branche d'intégration (le «maître» ou «stable»). Au lieu de cela, ils doivent soit utiliser des branches de fonctionnalité, soit créer de nouvelles branches distantes lors de la validation (par exemple: "git push origine HEAD: refs/heads/myNewFeature"). Vous pouvez également configurer votre référentiel GIT pour accepter uniquement les validations sur la branche d'intégration de Jenkins.

Vous avez terminé. Les validations doivent maintenant être fusionnées automatiquement avec la branche d'intégration (elles échoueront si elles ne sont pas fusionnées correctement) et construites. Si la génération réussit, le résultat de la fusion sera repoussé vers le référentiel git distant.

Ce que je comprends est,

  1. Les développeurs créent des branches à distance, à partir de laquelle jenkins va tirer de
  2. jenkins va fusionner la branche avec sa branche d'intégration et de construire
  3. Si la construction réussit, la fusion sera poussée à béni-repo/maître.

La question est, si la construction échoue, quel est l'état de la branche d'intégration? Je suppose seulement que cela revient en quelque sorte à l'engagement avant la fusion. Sinon, la branche d'intégration conserverait la fusion qui a brisé la construction, rendant impossible la fusion et la construction d'autres branches.

Est-ce vrai? Malheureusement, ce n'est pas clair sur le wiki.

Est-ce que quelqu'un connaît un exemple que je peux regarder?

+0

J'ai une question similaire ici, à savoir [comment utiliser la fusion de branche de pré-build de Jenkins uniquement pour les branches que je veux réellement fusionner] (http://stackoverflow.com/questions/22732145/how-to-use-jenkins -pre-build-branch-fusion-only-for-branches-i-want-to-merge) au lieu de tous ceux – nh2

+0

Cochez cette case: http: //www.yegor256.com/2014/07/24/rultor-automated-merging.html – yegor256

Répondre

2

D'après ce que je peux voir la GitSCM.checkout method, la fusion commence d'abord par une caisse, et, si la fusion échoue, restaurer la branche candidate avec une autre caisse:

// checkout origin/blah 
ObjectId target = git.revParse(mergeOptions.getRemoteBranchName()); 

git.checkoutBranch(paramLocalBranch, target.name()); 

try { 
    git.merge(revToBuild.getSha1().name()); 
} catch (Exception ex) { 
    // We still need to tag something to prevent 
    // repetitive builds from happening - tag the 
    // candidate 
    // branch. 
    git.checkoutBranch(paramLocalBranch, revToBuild.getSha1().name()); 
    [... tag applied ...] 
    buildData.saveBuild(new Build(revToBuild, buildNumber, Result.FAILURE)); 
    throw new AbortException("Branch not suitable for integration as it does not merge cleanly"); 
} 

Je ne pense donc pas La fusion échouée a des conséquences sur les générations suivantes.

Questions connexes