mirror of
https://github.com/samsonjs/rack-attack.git
synced 2026-04-22 14:05:58 +00:00
eaaa60ec44
I am starting to find it difficult to argue in favor of having jruby in the list of TravisCI rubies. It adds a bit of extra cost in maintenance and time spent waiting build to finish, without feeling we're getting a lot out of it. Thus, the feeling is that it has low ROI. Reasons behind my feeling of not "getting a lot out of it" includes: - Almost never coming across a situation in which I thought to myself "Hey, with this change we're making the gem incompatible with jRuby" because most of the failures on jRuby builds where either heisenbugs and/or rvm installation problems with jRuby, at least in my experience - Usage share seems to be very very low, even compared to unmaintaned MRI version, according to some sources, e.g. https://semaphoreci.com/blog/2017/11/08/ruby-versions-used-in-commercial-projects-in-2017.html
36 lines
718 B
YAML
36 lines
718 B
YAML
language: ruby
|
|
cache: bundler
|
|
|
|
rvm:
|
|
- 2.6.0-preview2
|
|
- 2.5.1
|
|
- 2.4.4
|
|
- 2.3.7
|
|
|
|
before_install:
|
|
- gem update --system
|
|
- gem install bundler
|
|
|
|
gemfile:
|
|
- gemfiles/rack_2_0.gemfile
|
|
- gemfiles/rack_1_6.gemfile
|
|
- gemfiles/rails_5_2.gemfile
|
|
- gemfiles/rails_5_1.gemfile
|
|
- gemfiles/rails_4_2.gemfile
|
|
- gemfiles/dalli2.gemfile
|
|
- gemfiles/redis_4.gemfile
|
|
- gemfiles/connection_pool_dalli.gemfile
|
|
- gemfiles/active_support_redis_cache_store.gemfile
|
|
- gemfiles/active_support_redis_cache_store_pooled.gemfile
|
|
- gemfiles/redis_store.gemfile
|
|
- gemfiles/active_support_redis_store.gemfile
|
|
|
|
matrix:
|
|
allow_failures:
|
|
- rvm: 2.6.0-preview2
|
|
|
|
fast_finish: true
|
|
|
|
services:
|
|
- redis
|
|
- memcached
|