Tomcat + Hudson and testing a Django Application

I'm using Hudson for the expected purpose of testing our Django application. In initial testing, I would deploy Hudson using the war method:

java -jar hudson.war

This worked great. However, we wanted to run the Hudson instance on Tomcat for stability and better flexibility for security.

However, now with Tomcat running Hudson does not seem to recognize previously-recognized Python libraries like Virtualenv. Here's an output from a 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: c开发者_如何学Pythonommand not found

virtualenv and pip were both installed using sudo easy_install, where are they?

virtualenv: /usr/local/bin/virtualenv

pip: /usr/local/bin/pip

Hudson now runs under the tomcat6 user. If I su into the tomcat6 user and check for virtualenv, it recognizes it. Thus, I am at a loss as to why it doesn't recognize it there.

I tried removing the commands from a script and placing it line-by-line into the shell execute box in Hudson and still same issue.

Any ideas? Cheers.

You can configure your environment variables globally via Manage Hudson -> Environment Variables or per machine via Machine -> Configure -> Environment Variables (or per build with the Setenv plugin). It sounds like you may need to set the PATH and PYTHONPATH appropriately; at least that's the simple solution.

Edited to add: I feel as though the following is a bit of a rant, though not really directed at you or your situation. I think that you already have the right mindset here since you're using virtualenv and pip in the first place -- and it's not unreasonable for you to say, "we expect our build machines to have virtualenv and pip installed in /usr/local," and be done with it. Take the rest as you will...

While the PATH is a simple thing to set up, having different build environments (or relying on a user's environment) is an integration "smell". If you depend on a certain environment in your build, then you should either verify the environment or explicitly set it up as part of the build. I put environment setup in the build scripts rather than in Hudson.

Maybe your only assumption is that virtualenv and pip are in the PATH (because those are good tools for managing other dependencies), but build assumptions tend to grow and get forgotten (until you need to set up a new machine or user). I find it useful to either have explicit checks, or refer to explicit executable paths that are part of my defined build environment. It is especially useful to have a explicitly defined environment when you have legacy builds or if you depend on specific versions of your build tools.

As part of builds where I've had environment problems (especially on Windows with cygwin), I print the environment as the first build step. (But I tend to be a little paranoid proactive.)

I don't mean to sound so preachy, I'm just trying to share my perspective.

Just to add to Dave Bacher's comment:

If you set your path in .profile, it is most likely not executed when running tomcat. The .profile (or whatever the name is on your system) is only executed when you have a login shell. To set necessary environment variables, you have to use a different set of file. Sometimes they are called .env and they exist on global and user level. In my environment (AIX), the user level .env file can have a different name (name is set in the env variable either in global environment file (eg. /etc/environment) or by parameter, when starting the shell).

Disclaimer: This is for the IBM AIX ksh, but should be the same for ksh on other systems.

P.S. I just found a nice explanation for .profile and .env from the HP site. Notice that they speak of a login shell (!) when they speak about the execution of the .profile file.