Closed SampsonCrowley closed 4 years ago
for instance, I have absolutely no fear posting my databse.yml here for the world to see:
default: &default
adapter: postgresql
encoding: unicode
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
schema_search_path: public
development:
<<: *default
database: down_under_sports_six_development
test:
<<: *default
database: down_under_sports_six_test
production:
<<: *default
url: <%= ENV['DATABASE_URL'] %>
Great question. This is something I'd like to fix!
The history behind this is that I ran into cases where different developers on a given team would have their PostgreSQL installed slightly differently. Some required connecting with a username postgres
, some required a password, some not. So a single database.yml
config wouldn't work for everyone. By putting it in .gitignore
, then each developer could customize it to work on their machine.
These days everyone I know seems to install PostgreSQL via homebrew, so there is a lot more consistency. So a single database.yml
checked into source control should work out of the box for most people. To handle edge cases people can use environment variables to override the defaults; e.g. PGHOST
, PGUSER
, etc.
Does that sound like the right approach?
I'm curious how you personally deploy to something like heroku when database.yml is not in the repo that will be compiled
FYI Heroku automatically creates the database.yml
for you, which is why an app without a database.yml
can still be deployed:
Fixed in 2fb82a0
huh, I had no idea that was part of the buildpack and I even have contributed to it before
Yeah I would say those edge cases are getting increasingly rare on development machines, but they should always be handling those with env variables, not with secrets in the yml file, so your update shouldn't cause problems for anyone doing things the right way
database.yml
should never contain sensitive secrets directly.I'm curious how you personally deploy to something like heroku when database.yml is not in the repo that will be compiled