You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We deploy our projects to multiple release stages, but they all have RAILS_ENV set to production. I think this is a good way to keep the environments in sync, Heroku also agree with me.
When using the bugsnag gem, it currently overrides BUGSNAG_RELEASE_STAGE set in the environment with the current RAILS_ENV value. I think it would be better that RAILS_ENV is only used if BUGSNAG_RELEASE_STAGE is not set.
I have a workaround for this, but I'd prefer not having to add this to all our projects.
We deploy our projects to multiple release stages, but they all have
RAILS_ENV
set toproduction
. I think this is a good way to keep the environments in sync, Heroku also agree with me.When using the bugsnag gem, it currently overrides
BUGSNAG_RELEASE_STAGE
set in the environment with the currentRAILS_ENV
value. I think it would be better thatRAILS_ENV
is only used ifBUGSNAG_RELEASE_STAGE
is not set.I have a workaround for this, but I'd prefer not having to add this to all our projects.
What do you think about changing the precedence of
RAILS_ENV
andBUGSNAG_RELEASE_STAGE
?The text was updated successfully, but these errors were encountered: