Alternative to #23638 log to STDOUT via env var #23734
People who deploy to containers or other places where they might have some sort of a log wrapping service use stdout. With this change new rails apps can be configured to output to STDOUT via setting `RAILS_LOG_TO_STDOUT` to any value. This allows container images or services to set the value for all apps without having to modify configuration for each application. If an app wants to opt out, they can either delete from the env hash, or remove that configuration. cc/ @rafaelfranca
Let me try again since I'm ditching your work without trying to understand. Why environment variable is better than have people changing their environment file? I know there are contained environments but when you make a choice to deploy to these environments could not you also change your application so it works in the environment?
It's only 1 more env var and it lets me kill https://rubygems.org/gems/rails_12factor
I want that "just works" (TM) experience with my apps. Most people don't care about the minutia of running on production, they want things to work out of the box. That is why we log to disk by default in production, instead of require a config change to do it. If I am an agency that is making new rails apps for different marketing sites every day then it is much easier for them to configure their environment once than to configure each new app every time. There's very few things that a container cares about to be able to run an app. The app has to know what port is available, the container needs to be able to capture logs, and in the case of Rails we want to be able to serve static files without needing an intermediate server such as nginx. These are the three configuration via environment variables experience that I am most interested in, and logging to STDOUT is the only one that doesn't work on master right now.
Can't that be done using a generator template?
That application would work out of box and would also let heroku or any contained environment go crazy and set what they thing it is important for them.
I know. I want that too and the current configuration file "just works".
You are describing app generator template feature.
In fact I was against the
If all we want is to new application "just works" in contained environments I'd go with a generator template.
I'll trade you
To my knowledge the presence of the static file PR hasn't had any significant cost to Rails maintenance. People either use it or ignore it. I could make this PR a somewhat dense one liner, if we're concerned with line count. If your primary concern is my slowly replacing EVERY command with environment variables, I promise to not do that. I've promoted using env vars previously but don't think I've ever made a "this is the last one" statement before.
Terence previously tried to get STDOUT logging service and it was reverted 1a90550#commitcomment-2819166 though the reasons given are related to the presence or not of logging files. I don't think that is a good approach as it is too heavy handed. My other closed PR was an attempt at a "why not both" type solution which also appeared heavy handed. This PR is a pretty minimal, non-magical configuration addition. I can't imagine this causing any kind of maintenance burden.
I hear what you're saying about templates. It still feels like the wrong solution. It seems like a very high overhead for configuring one value. I don't see it as any better than the
Rails introduced a environment variables RAILS_LOG_TO_STDOUT in the template for new projects here: rails/rails#23734 This commit adds the same code to the discourse production environment, making it easy to configure logging to stdout in production for environments which already support log collection via stdout.