Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENV cleanup #32

Closed
knoopx opened this issue Jan 18, 2011 · 9 comments
Closed

ENV cleanup #32

knoopx opened this issue Jan 18, 2011 · 9 comments

Comments

@knoopx
Copy link
Contributor

knoopx commented Jan 18, 2011

Why do we dupe ENV, set RAILS_ENV to test and revert back to previous ENV? There are some steps I do not necessarily want to execute into test ENV. Maybe we should make this behaivour parametrizable?

@michalbugno
Copy link
Member

This part of code requires some attention, bigtuna should use Bundler.with_clear_env there but something didn't work for us when creating bigtuna. I'll take a look into this part and try to fix it -- no params should be set there.

@knoopx
Copy link
Contributor Author

knoopx commented Jan 18, 2011

does this mean that bigtuna is a CI for rails-only applications?

@michalbugno
Copy link
Member

Nope, it runs arbitrary shell scripts. The env was set up so that it also supports rails apps.

@knoopx
Copy link
Contributor Author

knoopx commented Jan 18, 2011

also db:migrate RAILS_ENV=development does not override the default one set by with_clear_env

@michalbugno
Copy link
Member

You can try the branch:
https://github.com/appelier/bigtuna/tree/runner_env_fix

And see if it works for you: it uses the Bundler.with_clean_env and doesn't set any env's. If you want to set the env yourself it might be insufficient (although I'm not sure) to use ENV_NAME=env_value script/to/run

You probably want to use 'env' command
env ENV_NAME=env_value script/to/run

Let us know if the solution works for you! :-)

@wuputah
Copy link
Contributor

wuputah commented Jan 22, 2011

+1. Confirmed this works great for us on a fairly quirky setup - our setup had issues under the default setup (we had to change BigTuna to delete the RAILS_ENV environment variable under the default setup).

@cldwalker
Copy link

+1

@wuputah
Copy link
Contributor

wuputah commented Feb 2, 2011

Recently discovered that we hadn't restarted our workers when we tried this, so we discovered a small problem - not one necessarily for Bigtuna to fix, but some people might run into this. Since bundler captures the ENV when it is loaded in config/boot.rb, the environment variable BUNDLE_GEMFILE is set (Rails sets this in config/boot.rb) even inside Bundler.with_clean_env. This will affect any build scripts trying to use Bundler. The workaround is to use the --gemfile option with bundle install and use BUNDLE_GEMFILE=%build_dir%/Gemfile in your build script. For example:

bundle install --path=%project_dir%/bundle --deployment --gemfile=%build_dir%/Gemfile
BUNDLE_GEMFILE=%build_dir%/Gemfile bundle exec rake

In the future it may be useful for Bigtuna to have an "environment variables" configuration section which will be applied to the entire build process (the above is an example - our build process is more complicated, and we have to set the environment variables on every line).

@michalbugno
Copy link
Member

The issue is resolved, branch is merged into dev and regarding wuputah's comment I've created https://github.com/appelier/bigtuna/issues/issue/44

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants