ruby-on-railsruby-on-rails-4puma-dev

How does a Rails app set its Environment (Dev., Staging, etc.)?


Having a very confusing issue

My local app is running in its staging environment. I use puma-dev for the server and when I tail it by running tail -f ~/Library/Logs/puma-dev.log it says that the environment is development, but when I log out to my view using <%= Rails.env %> it says staging and the app tries to use any staging environment variables that it needs instead of the variables for the development environment.

The app has environments for Development, Staging, Test and Production. It is only recently that I noticed this was running in staging, I'm not exactly sure how or when it switched over but for the last couple years it was running in dev just fine, I recently added a staging env to help with a rails upgrade and some point over the last week this started running in staging.

I always thought this was set by the server when started but with puma-dev saying its env is development. I am at a loss for how this is trying to run in staging.

puma-dev output when starting:

io[19626]: Puma starting in single mode...
io[19626]: * Version 4.3.5 (ruby 2.4.6-p354), codename: Mysterious Traveller
io[19626]: * Min threads: 0, max threads: 5
io[19626]: * Environment: development

Can anyone shed some light on exactly where or how a Rails app decides to set its Environment because for the life of me, I cannot find it in the app.

As a test based on the answer below (which was useful) I log out these 3 variables:

  1. <%= Rails.env %> which ends up being staging
  2. <%= ENV["RAILS_ENV"] %> which ends up showing nothing
  3. <%= ENV["RACK_ENV"] %> which ends up being development

Also, if I run the rails console and type in Rails.env is also returns 'development'.

I also used the suggestion in the answer below and ran RAILS_ENV=development rails server. When doing that, both ENV["RAILS_ENV"] and ENV["RACK_ENV"] were set to development but the application was still running in staging (so the first variable above didn't change but the second one did).

The app is still trying to use all the staging ENV variables that are set (S3, etc.). For this app I also recently updated from Rails 3.* to 4.2 (I know these versions are old. I inherited the apps and am working on it). Which was the reason for adding the staging Environment. I was unable to find anything in the upgrade guides that talks about this kind of issue so I, at first, didn't suspect it was related but I wanted to give as much info as I could on this issue.


Solution

  • Finally figured it out today.

    Since adding the staging environment to the application I guess I needed to add some config files inside a puma directory in the app itself to help puma figure out what it needed to do.

    To be honest I'm still not sure why I needed this since puma would say it was running in development, which I thought was setting the environment.

    What I did was add a puma directory inside the config directory and then I added a file named development.rb and in there put the setting for running in the development environment.

    Content of puma/development.rb:

    #!/usr/bin/env puma
    root = "/Path/to/the/application"
    daemonize false
    environment "development"
    directory root
    pidfile "#{root}/tmp/pids/puma.pid"
    stdout_redirect "#{root}/log/puma_stdout.log", "#{root}/log/puma_stderr.log", true
    workers 2
    threads 8,32
    bind "unix:///#{root}/tmp/sockets/puma.sock"
    bind "tcp://0.0.0.0:8080"
    preload_app! 
    

    It nows runs as expected on my local machine.