DOC setting up build environment

[calmh]

There are environment variables set that cause Rails applications to fail, at least when deployed with Passenger. Specifically, RUBYOPT and RACK_ENV needs to be unset before trying to test a Rails application.

[qrush]

I came across this as well, and posted on the ML about it.

I ended up with this patch, sr didn't want to merge it in though.

http://gist.github.com/273075

[lackac]

This also solved my issue where building a Rails app using bundler failed because of the already loaded rack 1.1.0.
Thanks.

[adambair]

/opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:280:in `activate': can't activate rack (~> 1.0.0, runtime) for ["actionpack-2.3.5"], already activated rack-1.1.0 for [] (Gem::LoadError

Thanks qrush - your patch solved the issue I was having.

[botandrose]

+1 thanks!

Fixed my problems too. Why wouldn't sr accept it? Seems like a clearcut bug to me.

[mocoso]

+1

Sr could you share your reasons for not committing this to master?

[dougal]

-1

These seems very much like an environment issue rather than an Integrity issue. Integrity allows you to run code, and has little to do with making sure the host environment is setup in an appropriate way for your app. If you wish these environment variables to be unset, add this to the command that is run for your project.

[botandrose]

@dougal, I'd agree, except that these undesired environment variables are set by integrity itself. Since integrity is responsible for launching the new process to run your apps' tests in, I think it falls squarely to integrity to ensure that it doesn't let its own environment bleed into the new process.

[khelal]

I can confirm that I had the same exact problem and the patch fixed it.

[sr]

Maybe populate the command field with /usr/bin/env -i

[mocoso]

/usr/bin/env -i blows away the environment completely and so generally you will then have to put in a fair amount of work to recreate the elements of your environment that your project does need to build successfully.

This is why qrush's patch just undoes the changes made by integrity

[grahamc]

Thank you, @qrush for the patch - I'll look into merging it in tomorrow.

Thank you,
Graham

[kagminjeong]

The patch is a hack - it deletes everything with vendor from path and rubyopt, however it is possible that either had entries with vendor in them before integrity started, as well as integrity could have added entries without vendor in them.

The intent of it seems to be to restore path and rubyopt to what they were before integrity started, in which case a possible solution/work-around would be to run the build command in a login shell.

If a guaranteed-clean environment is desired, env -i should be used as mentioned by sr above.

Another option is not requiring bundler from integrity. In this case only rubyopt should need to be set for integrity to work, and build command would need to only unset rubyopt without destroying path.

This is the mailing list thread where the patch above was proposed: http://librelist.com/browser//integrity/2009/12/3/integrity-path-leaking-into-builds/

[kagminjeong]

My current approach is to source ~/.zshenv in the build command to get the environment back to pristine state.

[kagminjeong]

I'm going to close this.

As an administrator deploying integrity you know that both integrity and the projects it is testing require certain environments. You may be using the same environment for both or different environments.

If, as an administrator, you want to start the project in a clean environment you can clear or alter environment variables as part of the build command, externally to the project being tested.

If you have a single global environment, you may want to reuse it from integrity to the project being tested. This is currently possible as well.

I am open to documentation patches explaining the various arrangements.