Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade to rails 5 #3414

Merged
merged 73 commits into from
Apr 23, 2019
Merged

Upgrade to rails 5 #3414

merged 73 commits into from
Apr 23, 2019

Conversation

microweb10
Copy link
Member

@microweb10 microweb10 commented Mar 31, 2019

References

Objectives

  • Update CONSUL to use Rails 5.0.7.2 🎉

Visual Changes

None

Notes

  • This is a major update, so be careful when updating your current CONSUL installation
  • Considering reading the official Ruby on Rails guide when upgrading your CONSUL installation with this PR

@microweb10 microweb10 self-assigned this Mar 31, 2019
app/models/user.rb Show resolved Hide resolved
app/models/poll.rb Show resolved Hide resolved
app/models/budget/heading.rb Show resolved Hide resolved
app/models/budget/group.rb Show resolved Hide resolved
Gemfile Show resolved Hide resolved
@microweb10 microweb10 added this to Doing in Roadmap Mar 31, 2019
@microweb10 microweb10 force-pushed the upgrade_to_rails_5 branch 5 times, most recently from 584a746 to 5939e66 Compare April 4, 2019 16:21
microweb10 and others added 21 commits April 16, 2019 17:28
Uniq is deprecated
DEPRECATION WARNING: uniq is deprecated and will be removed from Rails
5.1 (use distinct instead) (called from block in <class:User> at
/home/travis/build/consul/consul/app/models/user.rb:67)
Devise api changed autorize path method
Since Globalize gem update to v5.2.0 we cannot override translations
anymore in the same way that before the update. Milestone::Translation
class removed in this commit were no longer loaded correctly when
translation class is retrieved by translation_class method provided by
Globalize. Here is the diff between both gem versions:

globalize/globalize@v5.0.0...v5.2.0#diff-a1370b109e0dd567545b072bc6447b8fR51

This problem is not happening on test environment but is throwing an
exception in other environments as it has not loaded the delegation
definition inside our custom translation class.

To fix this we added a new class method inside globalizable model
concern to allow to define method delegation on translations classes from
parent globalizable classes when needed without having to override
Translation classes.

Another way to properly load our custom Milestone::Translation class is
to place it inside parent model class, like the example below:

class Milestone
...

  class Translation
    delegate :status_id, to: :globalized_model
  end
end

Or maybe monkey patching translation_class method from globalize gem
to make it find our custom translation class. I don't like this option.
Since Globalize gem update to v5.2.0 we cannot override translations
anymore in the same way that before the update. Milestone::Translation
class removed in this commit were no longer loaded correctly when
translation class is retrieved by translation_class method provided by
Globalize. Here is the diff between both gem versions:

globalize/globalize@v5.0.0...v5.2.0diff-a1370b109e0dd567545b072bc6447b8fR51

This problem is not happening on test environment but is throwing an
exception in other environments as it has not loaded the delegation
definition inside our custom translation class.

To fix this we added a new class method inside globalizable model
concern to allow to define method delegation on translations classes from
parent globalizable classes when needed without having to override
Translation classes.
Since Globalize gem update to v5.2.0 we cannot override translations
anymore in the same way that before the update. Milestone::Translation
class removed in this commit were no longer loaded correctly when
translation class is retrieved by translation_class method provided by
Globalize. Here is the diff between both gem versions:

globalize/globalize@v5.0.0...v5.2.0diff-a1370b109e0dd567545b072bc6447b8fR51

This problem is not happening on test environment but is throwing an
exception in other environments as it has not loaded the delegation
definition inside our custom translation class.

To fix this we added a new class method inside globalizable model
concern to allow to define method delegation on translations classes from
parent globalizable classes when needed without having to override
Translation classes.

Another way to properly load our custom Translation class is
to place it inside parent model class.
Since Globalize gem update to v5.2.0 we cannot override translations
anymore in the same way that before the update. Milestone::Translation
class removed in this commit were no longer loaded correctly when
translation class is retrieved by translation_class method provided by
Globalize. Here is the diff between both gem versions:

globalize/globalize@v5.0.0...v5.2.0diff-a1370b109e0dd567545b072bc6447b8fR51

This problem is not happening on test environment but is throwing an
exception in other environments as it has not loaded the delegation
definition inside our custom translation class.

To fix this we added a new class method inside globalizable model
concern to allow to define method delegation on translations classes from
parent globalizable classes when needed without having to override
Translation classes.

Another way to properly load our custom Milestone::Translation class is
to place it inside parent model class.
Since Globalize gem update to v5.2.0 we cannot override translations
anymore in the same way that before the update. Milestone::Translation
class removed in this commit were no longer loaded correctly when
translation class is retrieved by translation_class method provided by
Globalize. Here is the diff between both gem versions:

globalize/globalize@v5.0.0...v5.2.0diff-a1370b109e0dd567545b072bc6447b8fR51

This problem is not happening on test environment but is throwing an
exception in other environments as it has not loaded the delegation
definition inside our custom translation class.

To fix this we added a new class method inside globalizable model
concern to allow to define method delegation on translations classes from
parent globalizable classes when needed without having to override
Translation classes.

Another way to properly load our custom Milestone::Translation class is
to place it inside parent model class.
Since Globalize gem update to v5.2.0 we cannot override translations
anymore in the same way that before the update. Milestone::Translation
class removed in this commit were no longer loaded correctly when
translation class is retrieved by translation_class method provided by
Globalize. Here is the diff between both gem versions:

globalize/globalize@v5.0.0...v5.2.0diff-a1370b109e0dd567545b072bc6447b8fR51

This problem is not happening on test environment but is throwing an
exception in other environments as it has not loaded the delegation
definition inside our custom translation class.

To fix this we added a new class method inside globalizable model
concern to allow to define method delegation on translations classes from
parent globalizable classes when needed without having to override
Translation classes.

Since module Sanitizable takes care of traslations, it's enough to
include the module in order to correctly sanitize the description.
xuanxu and others added 19 commits April 17, 2019 17:40
If tests run very fast all votes are created within the last 24
hours, so hot_score has the same value if the creation date for the
votes is Time.current or 1.day.ago.

Creating the votes 48 hours ago we make sure hot_score has the
correct value and the tests pass correctly.
Metrics/LineLength: Line is too long.
RSpec/InstanceVariable: Use let instead of an instance variable.
Layout/TrailingBlankLines: Final newline missing.
Style/StringLiterals: Prefer double-quoted strings.
There was a security vulnerability with previous version

heartcombo/devise#4981
This patch adds 2 missing colons (:) for 2 migrations that are failing when
the `rake db:migrate` task is ran. Whilst already-committed-to-source-control-
and-ran-on-production-environments migrations shouldn't be modified whatsoever,
this change does not modify in any way the current database schema so, technically,
it shouldn't affect forks that might have ran these migrations already and those
CONSUL installations that haven't done so should be able to without problems
DEPRECATION WARNING: Directly inheriting from ActiveRecord::Migration
is deprecated. Please specify the Rails release the migration was
written for:

class MigrationClass < ActiveRecord::Migration[4.2]

(called from require at bin/rails:4)
DEPRECATION WARNING: [Devise] `DeviseHelper.devise_error_messages!`
is deprecated and it will be removed in the next major version.
To customize the errors styles please run `rails g devise:views` and
modify the `devise/shared/error_messages` partial.

We will render the resource errors instead fo calling the deprecated method.
For some reason the paperclip method `attachment.exists?' was
returning nil even when `attachment.url(style)' was correctly
returning the url/path of the attachment.

Therefore returning `nil' was causing to raise an error in the
method `image_tag'.

With this change we make sure we return the image url it it's
available, or an empty string if it's not, but never a null value.
Because autoloading is disabled in production with Rails 5,
using autoload_paths will not load needed classes from
specified paths. The solution to this, is to ask Rails
to eager load classes.

https://sipsandbits.com/2017/02/14/upgrading-a-ruby-on-rails-application/
New version of globalize uses RequestStore gem to store I18n.locale and
Globalize.fallbacks in a per request basis to avoid collissions between
different requests. This gem update broke Globalize.fallback results
because it tries to fetch fallbacks from RequestStore, where there is no
locale fallbacks definition.
spec/lib/tasks/dev_seed_spec.rb:8
This test was failing and we could see messages like:

db/dev_seeds/polls.rb:147:
warning: toplevel constant Answer referenced by Poll::Answer

Resulting in the error:

rake db:dev_seed seeds the database without errors
  Failure/Error: expect { run_rake_task }.not_to raise_error
    expected no Exception, got #<ActiveModel::UnknownAttributeError:
    unknown attribute 'question_id' for Answer

Apparently the lookup was not correclty being performed, due to
conflicting names.

"Naming conflicts of this kind are rare in practice, but if one
occurs, require_dependency provides a solution by ensuring that
the constant needed to trigger the heuristic is defined in the
conflicting place."

https://guides.rubyonrails.org/v5.0/autoloading_and_reloading_constants.html
Rails 5 changed the initialization order, and now our initializers were
running before the `append_assets_path` initializer for each engine,
which prepended application assets to the custom assets we prepended in
the initializer.

Moving the code to the `config.after_initialize` code didn't work
either, since the paths added there were ignored by the application.

Adding another initializer to the Rails Engine is a hack, but solves the
problem.
@voodoorai2000 voodoorai2000 merged commit b230cd2 into master Apr 23, 2019
@voodoorai2000 voodoorai2000 deleted the upgrade_to_rails_5 branch April 23, 2019 14:26
This was referenced Apr 26, 2019
@voodoorai2000 voodoorai2000 moved this from Doing to Upstream in Roadmap Apr 26, 2019
@voodoorai2000 voodoorai2000 moved this from Upstream to Release 1.0.0-beta in Roadmap Apr 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

include Searchable breaks db:setup in production
9 participants