… request. This originated from a problem @jeg2 had: https://twitter.com/jeg2/status/271006838852579328 https://gist.github.com/4121410
…case header keys. See typhoeus/typhoeus#227 for more info. This is a hack that hopefully we won't have to do in the future, but it'll work for now.
This is necessary because it has conditional logic based on which typhoeus version has been loaded. The monkey_patches file loads typhoeus.
Even though the bundler team recommends against this for gems, I like having the record of what gem versions the build passed against at specific points in the git history.
I'm having FFI problems on JRuby and Rubinius.
@i0rek moved the new typhoeus faraday adapter into typhoeus itself.
The HTTP requests timeout (presumably due to switching to a threaded server instead of a forked one) on 1.8.7. We can safely skip them as there isn't any patron-specific logic in VCR.
I can't repro the travis failure locally so hopefully this'll provide the missing info.
I think this may help solve the travis CI build problems--the forked process may be exiting with another status code causing a failed spec run even though no specs failed. The forked process approach was needed for Patron in the past but that appears to be fixed.
The coverage check runs at the end and should run against the code coverage from the full spec build.
- It wasn't picking up gems in a group. - I got an undefined method error from `platforms`.
…case_of_multiline_scenario_description Feature/scenario name in case of multiline scenario description
Just like features, scenarios can have multiline preambles. When using the :use_scenario_name option, VCR will only use the first line of the scenario name as the directory for the cassette. This change is modeled after commit 034bdaf
- It should be required from `configuration` since that's the one place it's used now. - request_matcher_registry_spec and structs_spec should be runnable in isolation.