Downgrade Bundler on Travis #960
Conversation
Bundler 2.0.1 works with Rails, but [the released version of bundler-audit hardcodes a dependency on 1.x]. [Downgrade Bundler on Travis] until [the new bundler-audit] is out. [the released version of bundler-audit hardcodes a dependency on 1.x]: rubysec/bundler-audit#202 [Downgrade Bundler on Travis]: https://docs.travis-ci.com/user/languages/ruby/#bundler-20 [the new bundler-audit]: rubysec/bundler-audit#203
mike-burns
force-pushed
the
fix-for-bundler-2
branch
from
c6911d3
to
a0b8511
Compare
|
Is Bundler Audit needed for projects using GitHub given their security alert feature? https://blog.github.com/2017-11-16-introducing-security-alerts-on-github/ Wondering if another approach would be to keep latest Bundler but remove Bundler Audit. |
|
@croaky ah interesting, hadn't considered that. I'm going to bring that discussion to the rest of thoughtbot ( |
|
By itself, I do like the idea of tests failing when dependencies have a security vulnerability. It's a nice, reactive way (after you run CI or local tests) for your environment to encourage, or even enforce, that your gems are updated. It combines nicely with the GitHub feature of proactively (before you even run the tests) warning you that you're using dependencies with known security holes. Blocking bundler 2 and hardcoding for bundler 1.x is certainly a bummer though. |
Bundler 2.0.1 works with Rails, but the released version of
bundler-audit hardcodes a dependency on 1.x. Downgrade Bundler on Travis
until the new bundler-audit is out.