A single database.yml checked into source control should work out of the
box for most developers. To handle edge cases people can use environment
variables to override the defaults; e.g. PGHOST, PGUSER, etc.
In production the standard approach is to set the DATABASE_URL env var.
- Use new executors and commands syntax
- Upgrade to PostgreSQL 12
- Install Node 12 and Yarn (needed for webpacker)
- Split static analysis, tests, and system tests into separate jobs
This fixes an error reported by the latest postgres docker image:
```
Error: Database is uninitialized and superuser password is not specified.
You must specify POSTGRES_PASSWORD for the superuser. Use
"-e POSTGRES_PASSWORD=password" to set it in "docker run".
You may also use POSTGRES_HOST_AUTH_METHOD=trust to allow all connections
without a password. This is *not* recommended. See PostgreSQL
documentation about "trust":
https://www.postgresql.org/docs/current/auth-trust.html
```
This template assumes that test-unit and Rails system tests will be
used, so any CLI options that disable tests will cause problems. Update
our validation of these options to take account for new ones and renamed
ones in the latest versions of Rails.
Fixes#23
Now that we are using 12-factor, the Rails environment for deployment
will always be "production", with the only differences per environment
being controlled via env vars. This means marco-polo is not helpful,
because it will always prompt "prod".
Docker containers set a HOSTNAME var by default which is not what our
`config.ru` is expecting. To avoid this conflict, change the name of the
variable we expect to RAILS_HOSTNAME. This allows a Docker container to
run the Rails app out of the box.
Fixes#21
Often times an app will be deployed without SSL initially before the
final DNS/hosting setup is finalized. Leave it off by default and allow
opt-in per deployment environment.
The `javascript_include_tag` helper is not used in webpacker (which is
standard for Rails 6). This means that our JavascriptHelper is no longer
useful.