2009-11-21 3 views
6

Le plugin git pour hudson fonctionne bien. Toutefois, le script de génération doit mettre à jour un numéro de version dans les fichiers du référentiel, valider et repousser vers le référentiel. Lorsque Hudson interroge à côté de vérifier les modifications, il entre dans une boucle infinie car il voit que commettre comme un "changement" construit à nouveau, ce qui valide une modification, donc il construit à nouveau, puis il valide un autre changement, etc. .. Vous avez eu l'idée.Hudson interroge la boucle infinie pour les changements dans le dépôt Git?

je me suis arrêté il, a couru un « journal git » dans chaque dépôt et comparé les derniers commettent ids sont exactement les mêmes en utilisant git ls-tree HEAD

En outre, Hudson dirige cette commande pour vérifier les modifications:

git fetch + refs/heads/: refs/remotes/origine/ ls-tree git TETE

depuis Hudson lui-même poussé la commettras de son référentiel d'espace de travail, et apparemment les résultats correspondent ls-arbre, comment peut- cette commande détermine qu'il y a eu un changement?

Il semble qu'il doit stocker les résultats de ls-tree avant de faire la construction et de la comparer à celle qui n'aura pas la dernière validation. Ah. Je peux essayer de désactiver l'engagement pour tester cette théorie.

Quoi qu'il en soit, plutôt que de résoudre n'importe quel problème dans le plugin git pour Hudson, que puis-je faire pour m'assurer à la fin de ma construction que les repos sont identiques et que Hudson le verra.

Comment résoudre ce problème? Des idées?

Wayne

+0

Effectivement. Lorsque le commit est commenté de sorte que le script ne pousse que vers quelques dépôts, cela fonctionne correctement. C'est-à-dire, Hudson reconnaît zéro changement et attend des changements sans bouclage. Alors, comment arrêter la boucle infinie. Il semble que le plugin git pour Hudson enregistre l'état repo après la récupération initiale pour la construction. Mais il semble qu'il devrait sauver l'état de repo après une construction réussie dans le cas où la construction a fait un engagement - ou au moins donner cela comme option. Tout le monde a une idée plus facile et plus rapide pour résoudre ce problème? – Wayne

+0

Oh, j'ai trouvé une branche du git-hudson-plugin sur github où quelqu'un d'autre semble avoir déjà géré cette situation. Je télécharge et je construis et j'essaierai ça. Encore une fois si quelqu'un a une meilleure solution, s'il vous plaît aviser. Je posterai si cela résout. – Wayne

Répondre

3

Et la réponse est! ...

Le plugin Hudson Git était déjà fourchue par quelqu'un pour ajouter cette fonctionnalité, il fonctionne bien. Encore, j'ai dû baisser la source et régler quelques problèmes mineurs.

Maintenant, cela fonctionne à merveille. La build valide, et le plugin Git repousse le repository sans boucle, pensant qu'il a encore changé.

Beaucoup d'amour!

Si quelqu'un d'autre a besoin de cette recherche de la branche tickzoom du plugin Hudson-GIT sur Github.com mais vérifiez pour voir si a déjà été intégré dans le projet principal. Le committer a dit qu'il était intéressé et qu'il prévoyait de combiner les fourchettes.

Wayne

+0

Oh. c'est cool! Il s'avère que le plugin Hudson Git gère déjà cette situation. Il le décrit sur la documentation et était sur ma tête il y a quelques jours. L'idée est de ne s'engager que dans les branches "caractéristiques". Ensuite, le serveur de génération fusionne d'abord la branche de fonctionnalité à une branche d'intégration, puis elle fait son travail. De cette façon, le serveur automatisé n'a jamais besoin d'avoir des fusions sans avance rapide et les validations se produisent dans la branche d'intégration dans le bon ordre. Impressionnant. Vous devez aimer le pouvoir de Git. – Wayne

5

Votre système de construction ne devrait avoir aucune interaction d'écriture avec votre système de contrôle de révision. Il ne devrait certainement pas pousser ces changements automatiquement.

Votre système de construction peut demander git (par exemple git describe, par exemple) ce que la révision actuelle est. Tout le reste est redondant et sujet aux erreurs.

Une autre chose que vous pouvez prendre en compte n'est pas d'interroger les modifications. Cela semble être une manière idiote d'opérer. (Certes, je suis un gros utilisateur de buildbot habitué à tout déclencher sur les événements.)

Le repo git qui est interrogé sait quand il change. Il devrait juste dire au système CI de commencer immédiatement une construction basée sur cela. Vous obtenez vos builds plus tôt et depuis qu'ils sont tous déclenchés, vous n'avez pas vos ordinateurs assis autour de faire beaucoup de travail sans raison valable.

+0

Malheureusement, l'écriture doit avoir lieu car la construction doit marquer la révision avec un numéro de version comme 0.5.6.135 et également mettre à jour les fichiers sources avec le numéro afin que les binaires compilés aient la révision. Cela permet de repérer les bogues dans le bon code source. Nous avions l'habitude d'utiliser SVN et ce plugin avait une option pour "ignorer" certains fichiers lors de l'interrogation pour les changements. Nous l'avons donc ignoré nos fichiers de version. Git est différent, bien sûr. Si vous connaissez un autre moyen d'accomplir la même chose, faites le moi savoir s'il vous plaît. – Wayne

+0

J'aime votre idée de ne pas interroger les changements en réalité. L'obstacle est également d'éviter la boucle infinie de la poussée de la construction automatique. Donc, cette méthode doit également avoir un moyen de comparer entre le trop. C'est complexe. Donc, interroger et comparer semble plus simple. Et interroger toutes les minutes pour les changements n'est certainement pas une sorte de travail pour un ordinateur à s'inquiéter de le faire. – Wayne

+0

FYI, je me rends compte maintenant pourquoi vous dites que la construction ne devrait jamais écrire dans le dépôt. Je l'ai tout mis en place et de travailler mais la machine de construction CI écrit et crée des commits non-fastword quand il le fait à la fin de la construction pendant que les codeurs continuent de coder et de commettre pendant la construction. Des exigences complexes mais nécessaires. Je posterai une autre question pour y remédier. – Wayne