Pending the next release of Thor which [fixes](006832ea32) calls to `ERB.new`, Railties CI log for Ruby 2.6 is flooded with so many warnings it is too long for Travis to handle:
```
/home/travis/.rvm/gems/ruby-head/gems/thor-0.20.0/lib/thor/actions/file_manipulation.rb:120: warning: Passing safe_level with the 2nd argument of ERB.new is deprecated. Do not use it, and specify other arguments as keyword arguments.
/home/travis/.rvm/gems/ruby-head/gems/thor-0.20.0/lib/thor/actions/file_manipulation.rb:120: warning: Passing trim_mode with the 3rd argument of ERB.new is deprecated. Use keyword argument like ERB.new(str, trim_mode: ...) instead.
/home/travis/.rvm/gems/ruby-head/gems/thor-0.20.0/lib/thor/actions/file_manipulation.rb:120: warning: Passing eoutvar with the 4th argument of ERB.new is deprecated. Use keyword argument like ERB.new(str, eoutvar: ...) instead.
The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).
The job has been terminated
```
https://travis-ci.org/rails/rails/jobs/372623604#L10000https://api.travis-ci.org/v3/job/372623604/log.txt
This patch forces installation of fixed Thor, and enables us to look at the the log.
ImageProcessing gem is a wrapper around MiniMagick and ruby-vips, and
implements an interface for common image resizing and processing. This
is the canonical image processing gem recommended in [Shrine], and
that's where it developed from. The initial implementation was extracted
from Refile, which also implements on-the-fly transformations.
Some features that ImageProcessing gem adds on top of MiniMagick:
* resizing macros
- #resize_to_limit
- #resize_to_fit
- #resize_to_fill
- #resize_and_pad
* automatic orientation
* automatic thumbnail sharpening
* avoids the complex and inefficient MiniMagick::Image class
* will use "magick" instead of "convert" on ImageMagick 7
However, the biggest feature of the ImageProcessing gem is that it has
an alternative implementation that uses libvips. Libvips is an
alternative to ImageMagick that can process images very rapidly (we've
seen up 10x faster than ImageMagick).
What's great is that the ImageProcessing gem provides the same interface
for both implementations. The macros are named the same, and the libvips
implementation does auto orientation and thumbnail sharpening as well;
only the operations/options specific to ImageMagick/libvips differ. The
integration provided by this PR should work for both implementations.
The plan is to introduce the ImageProcessing backend in Rails 6.0 as the
default backend and deprecate the MiniMagick backend, then in Rails 6.1
remove the MiniMagick backend.
There's no reason to block future versions of Capybara since we don't
_know_ they are going to break. How will we know if we have a
conservative option set? This change prevents us from blocking users who
want to upgrade in the future.
Reasons are that the Qu gem wasn't compatible since Rails 5.1,
gem development was stopped in 2014 and maintainers have
confirmed its demise. See issue #32273
We locked Minitest to 5.11.1 in #31799
because 5.11.2 included a breaking change.
The change was fixed in 5.11.3, so we no
longer need to lock in the version.
Queue_classic currently limits pg to "< 0.20".
It is therefore not used for rails CI tests. There has been
a bull request for a while (by a co-worker of mine), which
fixes the incompatibilities and extends dependencies to pg-1.x.
This patch add this pull request to the Gemfile as an interim
solution, until it is merged.
* Use `gem 'redis', '~> 4.0'` for new app Gemfiles
* Loosen Action Cable redis-rb dep to `>= 3.3, < 5`
* Bump redis-namespace for looser Redis version dep
* Avoid using the underlying `redis.client` directly
* Use `Redis.new` instead of `Redis.connect`
