Closed timdiggins closed 6 years ago
This looks great, thank you!
I'm a bit suspicious of the Travis change; no other Ruby project I run has required a config change like that recently. What was the original error #283 was fixing?
@gjtorikian
I think you're right to be suspicious, but I do think it (only partially -- see below) fixes the problem (without it I couldn't get travis to build even once)
Firstly note that it seems to have been a sporadic problem on master (some builds failed, some succeeded).
The failure that I think we're fixing here is:
$ bundle install --jobs=3 --retry=3 --deployment --path=${BUNDLE_PATH:-vendor/bundle}
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated gemfiles/rails_5.gemfile.lock to version control.
e.g. https://travis-ci.org/jch/html-pipeline/jobs/265274259#L321
This removes the --deployment
bundler arg (by overriding the default).
However I think the .lock files should also be removed... I was totally wrong about the idea that it was to do with trusty. This is still building on precise. I think the dist should be specified (given precise
or moved to trusty
) -- have moved to trusty and removed lockfiles in #285. Merge that and rebase?
Could you merge master
+ rebase to remove e27f50a7676480511e91f897ca56cc34a5fbcb9b from this PR? I'm still not entirely sure bundler_args
is necessary but if Travis fails without it, I'll deal with fixing it.
All done -- good to go!
Fantastic, thanks!
Out as 2.7.1.
Fixes #282. Depends on #283 for travis.
In the end it seemed cleaner (and safer) to create a tested utility-method for catching the LoadError and then reissuing with added information.
Currently in separate commits for ease of reading, but can squash /rebase if desired.