[Hudson] Droits pour lancer un build...
Bonjour, Serait-il possible de nous donner les droits nécessaires sur hudson pour lancer/forcer un build sur le projet mapstoragemanger ? Cela nous permettrait de relancer des builds suite à un build qui crash sans avoir besoin d'attendre le prochain build... et donc de mettre une ou plusieurs heures pour réparer le build (qui peut très bien marcher chez nous ce qui est assez handicapant...). Typiquement cette semaine, j'ai cassé deux fois le build et que j'ai résolu en deux builds (donc 1 h) pour réparer les erreurs, de même une fois au début du projet.. (j'ai du attendre 3 ou 4 h du mat pour arriver à faire passer un build que j'avais cassé vers 1h..). Et personnellement, tant que le build ne passe pas, je me concentre plus sur ça que sur le reste... En gros, si on peut faire cela ce serait cool, on aurait un rendement plus élevé, donc moins de temps à attendre... et durant le temps économisé on pourrait penser à la faim dans le monde... ou aux insomniaques.
Le jeudi 18 février 2010 à 20:47 +0100, Dorian Langlais a écrit :
Bonjour,
Serait-il possible de nous donner les droits nécessaires sur hudson pour lancer/forcer un build sur le projet mapstoragemanger ?
Il suffit juste de créer un compte et de se connecter il me semble. A vérifier
Le jeudi 18 février 2010 à 21:05 +0100, Florian Desbois a écrit :
Le jeudi 18 février 2010 à 20:47 +0100, Dorian Langlais a écrit :
Bonjour,
Serait-il possible de nous donner les droits nécessaires sur hudson pour lancer/forcer un build sur le projet mapstoragemanger ?
Il suffit juste de créer un compte et de se connecter il me semble. A vérifier
Peut-être en utilisant les identifiants du svn, je ne sais pas trop en fait :P
Dorian Langlais a écrit :
Bonjour,
Serait-il possible de nous donner les droits nécessaires sur hudson pour lancer/forcer un build sur le projet mapstoragemanger ?
Cela nous permettrait de relancer des builds suite à un build qui crash sans avoir besoin d'attendre le prochain build... et donc de mettre une ou plusieurs heures pour réparer le build (qui peut très bien marcher chez nous ce qui est assez handicapant...). Typiquement cette semaine, j'ai cassé deux fois le build et que j'ai résolu en deux builds (donc 1 h) pour réparer les erreurs, de même une fois au début du projet.. (j'ai du attendre 3 ou 4 h du mat pour arriver à faire passer un build que j'avais cassé vers 1h..). Et personnellement, tant que le build ne passe pas, je me concentre plus sur ça que sur le reste...
En gros, si on peut faire cela ce serait cool, on aurait un rendement plus élevé, donc moins de temps à attendre... et durant le temps économisé on pourrait penser à la faim dans le monde... ou aux insomniaques.
j'ai changé la configuration du projet hudson afin qu'il vérifie toutes les 5 minutes s'il y a eu un changement dans subversion.
On Fri, 19 Feb 2010 01:41:17 +0100 Stephane CHORLET <schorlet@codelutin.com> wrote:
Dorian Langlais a écrit :
Bonjour,
Serait-il possible de nous donner les droits nécessaires sur hudson pour lancer/forcer un build sur le projet mapstoragemanger ?
Cela nous permettrait de relancer des builds suite à un build qui crash sans avoir besoin d'attendre le prochain build... et donc de mettre une ou plusieurs heures pour réparer le build (qui peut très bien marcher chez nous ce qui est assez handicapant...). Typiquement cette semaine, j'ai cassé deux fois le build et que j'ai résolu en deux builds (donc 1 h) pour réparer les erreurs, de même une fois au début du projet.. (j'ai du attendre 3 ou 4 h du mat pour arriver à faire passer un build que j'avais cassé vers 1h..). Et personnellement, tant que le build ne passe pas, je me concentre plus sur ça que sur le reste...
En gros, si on peut faire cela ce serait cool, on aurait un rendement plus élevé, donc moins de temps à attendre... et durant le temps économisé on pourrait penser à la faim dans le monde... ou aux insomniaques.
j'ai changé la configuration du projet hudson afin qu'il vérifie toutes les 5 minutes s'il y a eu un changement dans subversion.
Stephane a repondu au probleme, mais il reste le probleme de fond, je ne comprend pas comment un outil annexe (hudson) qui pourrait tres bien ne pas existe, peut bloquer vos developpements :(. J'ai l'impression que vous prenez les choses a l'envers :( Vous ne developpez pas un projet pour qu'il build dans hudson, mais pour qu'il reponde a un besoin utilisateur. Hudson est juste la pour mettre en garde que quelqu'un a fait un mauvais commit et qu'il doit etre corrige. Normalement cette personne devrait avoir le meme probleme sur sa machine et donc pouvoir le regler localement puis commiter. Le temps de prise en compte dans hudson n'est vraiment pas important, si le projet etait en phase finale de developpement et qu'il doit etre deploye dans 1 heures, avoir un echec hudson serait problematique, mais la nous en sommes tres loin. -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Bonjour, En effet, néanmoins, comme je vous l'ai dit hier (il me semble), j'avais fait une erreur dans les noms des modules maven (msn-* au lieu de msm-*). Chez moi, je n'avais pas de problème : dans mon dossier ~/.m2/repositories/* il y avait bien les anciens artifacts msn-*.. donc je n'avais aucun soucis. Par contre, je ne sais pas comment hudson marche, mais sur hudson le build cassait suite à ce problème (j'avais modifié le pom parent... en donnant les bons noms...) vu qu'il avait du supprimer ces artifacts.... De mon coté, lorsque j'ai compris la source de l'erreur, la suppression des mauvais artifacts (msn-*) a directement entrainé le cassage du build. De même, comme je vous ai montré/dit, j'ai (ou il y a) un soucis avec les plugins maven-jaxx-plugin et maven-i18n-plugin qui ont respectivement pour groupId org.nuiton.jaxx et org.nuiton.i18n. Or ces artifacts se trouvent bien dans le dossier : http://maven.nuiton.org/release/org/nuiton/jaxx/* et http://maven.nuiton.org/release/org/nuiton/i18n/* au lieu de http://maven.nuiton.org/release/org/nuiton/* si le groupId était org.nuiton Il me faut les installer manuellement dans les dossier : ~/.m2/repository/org/nuiton/jaxx/maven-jaxx-plugin/2.0.0-beta-3 ~/.m2/repository/org/nuiton/jaxx/maven-i18n-plugin/1.0.1 Dans le pom mapstoragemanager, le repository du parent pom est bien renseigné : groupId : org.nuiton pour url : http://maven.nuiton.org/release/<http://maven.nuiton.org/release/org/nuiton/i18n/*> J'avais tenté d'ajouter deux autres repository : - groupId : org.nuiton.jaxx pour url : http://maven.nuiton.org/release/<http://maven.nuiton.org/release/org/nuiton/i18n/*> - groupId : org.nuiton.nuiton pour url : http://maven.nuiton.org/release/<http://maven.nuiton.org/release/org/nuiton/i18n/*> Sans le succès escompté. Hier, en tenant un mvn site:site, j'ai eu quelques soucis avec d'autres plugins maven. Malheureusement, on ne peut voir ces soucis sur une machine qui possède déjà les artifacts précédemment cité (suffit juste de les installer à la main). Peut-être simplement un soucis dans notre pom, or même si l'on a vu et utilisé maven l'année dernière (plus ou moins selon les options suivies), nous ne le maîtrisons pas entièrement. Par exemple, hier j'ai modifié tous nos modules maven pour qu'ils aient pour parent le projet mapstoragemanager et non mavenpom4redmine pour l'"héritage maven".. (erreur commise par moi-même). Il se peut aussi que je fais des commit "inutiles" parfois (type qualité -> sonar) ou pour passer un build sur hudson, c'est que je ne peux pas laisser quelque chose comme ça... Et d'ailleurs, j'espère que je n'embête pas Florent lorsque je touche son code pour améliorer la qualité. C'est clairement inutile ; je tente de me soigner en laissant les trucs qui vont être utile - typiquement des imports inutilisés à cause d'une ligne de code mise en commentaire - et j'essaie de laisser les "fautes" mineures sur ce dont je ne travaille pas. -- Dorian Langlais.
participants (4)
-
Benjamin POUSSIN -
Dorian Langlais -
Florian Desbois -
Stephane CHORLET