Our rubocop config hides all current violations. It allows us to have a
passing rubocop run on the current code and improve it gradually. It
detects new violations, but doesn't annoy us with all the existing ones.
Code Climate has its own way of remembering all current violations which
is more sophisticated than ours. The new config for Code Climate doesn't
hide any violations so that Code Climate can give us a realistic score
of code quality and warn us about every new violation.
Splitting the configuration into the main three parts gives a quicker
overview and makes maintaining the parts easier.
The file .rubocop_todo.yml is generated automatically and contains a
configuration to make all files pass. For a lot of cops it just lists
the offending files. But for some cops it sets a different metric.
Since we don't want these lax metrics, we override them in our config
file .rubocop.yml. This leads to a lot of offences again. This patch
lists all offending files for each cop to make rubocop pass. We can
improve the code over time and remove items from the list.
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**
Why:
* In a clean environment, running the new preferences migration fails,
due to a missing file from Spree core being manually required. This
file has now been missing since ab707cf.
This change addresses the issue by:
* Copying the missing file from Spree Core 1.3.6.beta into the migration.
This fixes the issue for now, but also means that a migration merge
and/or rewrite might be in order for the future.
