In Staging and Production we have two Redis instances running on two different ports. In dev that probably won't be set up, and Redis will be on port 6379 by default. These defaults mean it will work nicely out of the box.
- Via `view_component_storybook` : https://github.com/jonspalmer/view_component_storybook
- Configure both `view_component_storybook` and `storybook`
- Add two addons: `@storybook/addon-docs` and `@storybook/addon-controls`
Update config comment for clarity
The previous mechanism didn't seem to work and newer Rails versions have
an easier config for this now.
Also fixing all i18n errors which were now failing specs.
This fixes the following deprecation warnings
```
DEPRECATION WARNING: `config.serve_static_files` is deprecated and will be removed in Rails 5.1.
Please use `config.public_file_server.enabled = true` instead.
(called from block in <top (required)> at /home/runner/work/openfoodnetwork/openfoodnetwork/config/environments/test.rb:13)
DEPRECATION WARNING: `config.static_cache_control` is deprecated and will be removed in Rails 5.1.
Please use
`config.public_file_server.headers = { 'Cache-Control' => 'public, max-age=3600' }`
instead.
(called from block in <top (required)> at /home/runner/work/openfoodnetwork/openfoodnetwork/config/environments/test.rb:14)
```
Fixes the following deprecation warning:
```
DEPRECATION WARNING: The configuration option `config.serve_static_assets` has been renamed to `config.serve_static_files` to clarify its role (it merely enables serving everything in the `public` folder and is unrelated to the asset pipeline). The `serve_
static_assets` alias will be removed in Rails 5.0. Please migrate your configuration files accordingly. (called from block in <top (required)> at /usr/src/app/config/environments/test.rb:13)
```
I took this from a recent newsletter I read. Sometimes replication
performance issues locally is actually slower than production due to dev
mode settings (code reloading, etc.), heavy de-only gems and the asset
pipeline.
The PROFILE env var switches these settings all at the same time,
giving us an environment closer to production, essential for reliable
profiling. Then, rack-mini-profiler is going to be more accurate.
Apparently it's something
[RubyGems](b026df86ae/config/environments/development.rb (L72-L92))
and
[CodeTriage](a3c957647d)
both use.
The default was being ignored in our new logging configuration, and the actual log output was way too high. This was causing serious disk space issues.
Fixes several errors such as:
104) UserRegistrationsController via ajax sets user.locale from cookie on create
Failure/Error: I18n.locale = spree_current_user.andand.locale || cookies[:locale] || I18n.default_locale
I18n::InvalidLocale:
"pt" is not a valid locale
# ./app/helpers/i18n_helper.rb:14:in `set_locale'
# ./spec/controllers/user_registrations_controller_spec.rb:56:in `block (3 levels) in <top (required)>'
I don't know why but `Rails.logger` is still nil when evaluated from
`configure` block in `config/environments/development.rb`. The only way
I found to make ActiveSupport's cache to use the default logger is from
an initializer.
Note that `ActiveSupport::Cache::Store` uses `debug` level and so we
need to set the dev logger in that same level to see its messages. If
you want to debug in staging as well, you'll need to modify the log
level manually.
This way we don't need to touch the class implementation to enable the
products cache in development. Just change the default value in
`app/models/spree/app_configuration_decorator.rb`.
Why:
* Starting the environment, even with just `bundle exec rake`, results
in the following error:
```sh
Value assigned to config.time_zone not recognized.Run "rake -D time"
for a list of tasks for finding appropriate time zone names.
```
This change addresses the issue by:
* Adding the time zone setting to environment specific configurations,
defaulting to UTC in development, and using Melbourne in tests.
For some reason running `bundle exec rake db:migrate RAILS_ENV=staging`
fails with:
```
rake aborted!
NameError: uninitialized constant Spree::Config
```
Running `bundle exec rails server` for instance, does not. There must be
a difference on the way a rake task and the rails commands load the app.
Moving this configuration to an initializer, at the end of the
initialization process, fixes it. The constant `Spree::Config` is
already loaded.
**This is preventing the release v1.22.0 from being staged and tested**
