Trying to split out RAILS_ENV from RUBBER_ENV

[Dan Sadaka]

Greetings,

I am modifying rubber so I can have the RAILS environment out there running on separate instances for different developers.  For instance, I have a RUBBER_ENV=stage1 with servers stage1 and stagedb01
and I have a RUBBER_ENV=stage2  with servers stage2 stagedb02

This should be relatively easy.  I created a new entry in rubber.yml:

rails_env: "#{ENV['RAILS_ENV'] || Rubber.env}"

At the command line, I run

(export RAILS_ENV=staging;export RUBBER_ENV=stage2; cap deploy:cold)

which I know works because I added a puts statement in the on :load block in deploy.rb:

puts "Starting deploy with RAILS_ENV = #{ENV['RAILS_ENV']}, #{Rubber.config.rails_env} and RUBBER_ENV=#{Rubber.env}"

which correctly displays:

Starting deploy with RAILS_ENV = staging, staging and RUBBER_ENV=stage2


However, in all the templates.  (database.yml, crontab, etc.) Rubber.config.rails_env (and rubber_env.rails_env for that matter) is nil!

For instance, in passenger-apache-vhost.conf I have

RailsEnv  <%= Rubber.config.rails_env || Rubber.env %>

but I don't get staging, I get stage2, meaning I get Rubber.env instead of Rubber.config.rails_env.
what's happening to these variables between the time deploy.rb executes and these templates are filled?

Please help, I've been at this for hours.

Thanks,
Dan

[Dan Sadaka]

Anyone? This is holding up a new developer I have from working.

Thanks,
Dan

[Kevin Menard]

Hi Dan,

 

Sorry I'm just getting to this.

 

Instead of using "Rubber.config.rails_env" in your templates, can you try using "rubber_env.rails_env" and see if that makes a difference?

 

--

Kevin

--

You received this message because you are subscribed to the Google Groups "rubber" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rubber-ec2+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

[Dan Sadaka]

Kevin,

As I said in my first post:  "(and rubber_env.rails_env for that matter)", I tried rubber_env first before I read about Rubber.config.  Neither works.  I know it's running the local code I'm changing since if I use RailsEnv <%= Rubber.config.rails_env  %> instead of RailsEnv <%= Rubber.config.rails_env || Rubber.env %>  I just get nothing (empty string)

Any ideas?

Thanks,

Dan

[Dan Sadaka]

I finally got the time to trace through this issue and found the Culprit:

/Users/dsadaka/.rvm/gems/ruby-1.9.3-p392@esebco4/gems/rubber-3.1.0/lib/rubber/recipes/rubber/deploy.rb:127

rsudo "cd #{path} && RUBBER_ENV=#{Rubber.env} RAILS_ENV=#{Rubber.env} ./script/rubber config #{opts}"

As you can see the config script was being called with RAILS_ENV = Rubber.env causing all config vars to be reinitialized with the wrong value.  I guess I'll fork and make the change.

Dan

On Thursday, February 18, 2016 at 12:23:30 AM UTC-5, Dan Sadaka wrote:

[Kevin Menard]

Interesting. We should support having the two divorced. If you don't mind, please file an issue and I'll look at it when I can. I suspect using the bash syntax for a default value would be enough here.

 

--

Kevin

[Dan Sadaka]

Done.

Thanks,

Dan