Tomcat + Hudson et tester une application Django

Question

J'utilise Hudson dans le but de tester notre application Django. Dans les tests initiaux, je voudrais déployer Hudson en utilisant la méthode de guerre:

java -jar hudson.war 

Cela a fonctionné très bien. Cependant, nous voulions lancer l'instance Hudson sur Tomcat pour plus de stabilité et une meilleure flexibilité pour la sécurité. Cependant, maintenant que Tomcat s'exécute, Hudson ne semble pas reconnaître les bibliothèques Python précédemment reconnues comme Virtualenv. Voici une sortie d'un test:

 
+ bash ./config/testsuite/hudson-build.sh 
./config/testsuite/hudson-build.sh: line 5: virtualenv: command not found 
./config/testsuite/hudson-build.sh: line 6: ./ve/bin/activate: No such file or directory 
./config/testsuite/hudson-build.sh: line 7: pip: command not found 

virtualenv et pip ont tous deux été installés à l'aide sudo easy_install, où sont-ils?

virtualenv:/usr/local/bin/virtualenv

pip:/usr/local/bin/pip

Hudson dirige maintenant sous l'utilisateur tomcat6. Si je su dans l'utilisateur tomcat6 et vérifie virtualenv, il le reconnaît. Ainsi, je ne sais pas pourquoi il ne le reconnaît pas là.

J'ai essayé de supprimer les commandes d'un script et de les placer ligne par ligne dans la boîte d'exécution du shell dans Hudson et toujours le même problème.

Des idées? À votre santé.

Answer 1

Vous pouvez configurer vos variables d'environnement à l'échelle mondiale via Gérer Hudson -> Variables d'environnement ou par machine via machine -> Configurer -> Variables d'environnement (ou par construction avec le plugin Setenv). Cela ressemble à vous devrez peut-être définir le CHEMIN et PYTHONPATH de manière appropriée; au moins c'est la solution simple . Je me sens comme si ce qui suit est un peu une diatribe, mais pas vraiment dirigé vers vous ou votre situation. Je pense que vous avez déjà la bonne mentalité ici puisque vous utilisez virtualenv et pip en premier lieu - et il n'est pas déraisonnable de dire, "nous nous attendons à ce que nos machines de build aient virtualenv et pip installés dans /usr/local", et être fait avec. Prenez le reste comme vous voulez ...

Alors que le PATH est une chose simple à configurer, avoir différents environnements de construction (ou en s'appuyant sur l'environnement d'un utilisateur) est une «odeur» d'intégration. Si vous dépendez d'un certain environnement dans votre build, alors vous devez vérifier l'environnement ou le configurer explicitement dans le cadre de la construction. Je mets la configuration de l'environnement dans les scripts de construction plutôt que dans Hudson.

Peut-être votre seule hypothèse est que virtualenv et pip sont dans le PATH (parce que ce sont de bons outils pour la gestion d'autres dépendances), mais construire hypothèses ont tendance à croître et à s'oublier (jusqu'à ce que vous avez besoin de mettre en place une nouvelle machine ou utilisateur). Je trouve utile d'avoir des vérifications explicites, ou de me référer aux chemins explicites explicites qui font partie de mon environnement de construction défini.C'est particulièrement utile d'avoir un environnement explicitement défini quand vous avez des builds legacy ou si vous dépendez de versions spécifiques de vos outils de construction.

Dans le cadre de versions où j'ai eu des problèmes d'environnement (en particulier sur Windows avec cygwin), j'imprime l'environnement comme première étape de construction. (Mais j'ai tendance à être un peu paranoïaque proactive.)

Je ne veux pas paraître si moralisateur, je suis juste essayer de partager mon point de vue.

Answer 2

Juste pour ajouter au commentaire de Dave Bacher:

Si vous définissez votre chemin dans .profile, il est très probablement pas exécuté lors de l'exécution tomcat. Le fichier .profile (ou quel que soit le nom sur votre système) n'est exécuté que lorsque vous avez un shell de connexion. Pour définir les variables d'environnement nécessaires, vous devez utiliser un ensemble de fichiers différent. Parfois, ils sont appelés .env et ils existent au niveau global et de l'utilisateur. Dans mon environnement (AIX), le fichier .env au niveau de l'utilisateur peut avoir un nom différent (le nom est défini dans la variable env soit dans le fichier d'environnement global (par exemple/etc/environment) soit par paramètre au démarrage du shell). Clause de non-responsabilité: Ceci est pour IBM AIX ksh, mais devrait être le même pour ksh sur d'autres systèmes.

P.S. Je viens de trouver un joli explanation for .profile and .env sur le site HP. Notez qu'ils parlent d'un shell de connexion (!) Lorsqu'ils parlent de l'exécution du fichier .profile.