Remaining issues with docker development

[solebared]

Documenting a few outstanding issues with dockerized development:

1. Running bin/dev/test generates the following warning:

ActiveRecord::EnvironmentMismatchError: You are attempting to modify a database that was last run in `development` environment.
You are running in `test` environment. If you are sure you want to continue, first set the environment using:
        rails db:environment:set RAILS_ENV=test

Steps to recreate: Run bin/dev/bootstrap, then bin/dev/test.

1. Could be worth silencing warnings for now. There are still a few outstanding gems (eg mobility) that haven't fixed their warnings generated by newer rubies.

[indiebrain]

A few notes on what I think I've found so far...

ActiveRecord::EnvironmentMismatchError:

TLDR; I suspect that the development and test environments are sharing a database.

It seems that the development docker-compose.yml sets a default POSTGRES_DB ENV var value of mutualaid. This passes through to the application, and takes precedence in both the development AND test - IE development and test both use the mutualaid database. I currently believe this to be the cause of the ActiveRecord::EnvironmentMismatchError, and will put together a change set to address this.

[grenewode]

@indiebrain - I think your interpretation is correct. When I wrote these, I think I was only testing it against the docker-development configuration. When I originally the docker-development configuration, the the other configurations didn't pull values from environment variables:
https://github.com/rubyforgood/mutual-aid/blob/e10d0b05fd122130279d849b60e60ea80308caa8/config/database.yml#L24-L977
Since I didn't (and still don't) know that much about ruby configuration files, I didn't want to change the other configurations, so I created a new one for docker instead. At this point, I think you might be able to get rid of the docker-environment configuration altogether. It is only referenced in three places in the project. One of them is the database.yml configuration for docker your already looking at. I think others could be eliminated/unified as well:

1. mutual-aid/ansible/files/database.yml

   Lines 33 to 50 in 0a84965

   	development:
   	<<: *default
   	database: mutualaid_development
   	test:
   	<<: *default
   	database: mutualaid_test
   	production:
   	<<: *default
   	database: mutualaid
   	docker-development:
   	<<: *default
   	database: <%= ENV['POSTGRES_DB'] %>
   	username: <%= ENV['POSTGRES_USER'] %>
   	password: <%= ENV['POSTGRES_PASSWORD'] %>
   	host: <%= ENV['POSTGRES_HOST'] %>

   
   Basically the same (maybe should be identical/symlinked to) the docker configuration, but less up to date. I think this was mostly done by @padthaitofuhot when we were setting up LAMA's instances on ansible.

2. mutual-aid/config/webpacker.yml

   Lines 52 to 89 in 0a84965

   	development: &development-settings
   	<<: *default
   	compile: true
   	# Verifies that correct packages and versions are installed by inspecting package.json, yarn.lock, and node_modules
   	check_yarn_integrity: true
   	# Reference: https://webpack.js.org/configuration/dev-server/
   	dev_server: &development-server
   	https: false
   	host: localhost
   	port: 3035
   	public: localhost:3035
   	hmr: false
   	# Inline should be set to true if using HMR
   	inline: true
   	overlay: true
   	compress: true
   	disable_host_check: true
   	use_local_ip: false
   	quiet: false
   	pretty: false
   	headers:
   	"Access-Control-Allow-Origin": "*"
   	watch_options:
   	ignored: "**/node_modules/**"
   	docker-development:
   	<<: *default
   	compile: true
   	check_yarn_integrity: true
   	test:
   	<<: *default
   	compile: true
   	# Compile test packs to a separate directory
   	public_output_path: packs-test

   
   More complicated because of the webpack development server. It looks like the docker-development configuration is identical to the development configuration, except that the docker config has the webpack-dev-server disabled. I think I disabled the dev server because it doesn't really serve any purpose in a immutable docker image. However, if people are already using the vanilla development configuration with docker, and the dev server isn't causing any issues, there's no reason to bother turning it off.

[indiebrain]

@grenewode, thanks for the context - I'm still supa-green here, and ANY direction / guidance is most appreciated.

I think the development-docker config bits can go, they seem to be vestigial configuration and don't seem to be used. I'll put together a PR to remove them. I agree that the Ansible config might as well be a symlink to the native config, but I'm not big-city Ansible expert so I'll probably rely on the principal of "All of us are better than ANY of us" during code review.