-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
only require ntlm if ntlm auth was requested. #187
Conversation
LGTM 👍 |
@rogerleite no problem. I tried to up the coverage, but must be missing something... a bit new to coveralls. Any advice? |
@coldnebo sorry! No idea why coverage decreased ... 😐 |
So, coveralls says that coverage on lib/httpi/adapter/net_http.rb has fallen to 67.26%. If I run this locally:
So, it looks like there are two runs ( So let's run rspec just on the one:
Huh? Again, with more intensity...
net_http.rb isn't in the list? Maybe I haven't been testing this the whole time? Or maybe the SSL configuration is silently eating whole test cases? I noticed console errors both in my local and in Travis logs. I opened a parallel issue here: puma/puma#1381. So confusing. Last time I worked in this codebase was before Puma was added, so I may not be understanding? Need help to close this out. |
to retain coverage results. Rather than depend on the existing :spec and :spec_integration tasks, a better approach is to create a :ci Rspec task that includes all the files together. This solves the issue where Coveralls doesn't see test coverage runs for the :spec run because they are overwritten by the :spec)_integration run.
task :ci => [:spec, :spec_integration] | ||
RSpec::Core::RakeTask.new "ci" do |t| | ||
t.pattern = "spec/{httpi,integration}/**/*_spec.rb" | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌 🎯
Ah, soo close. I reopened the issue with the puma team to see if they can help. |
My investigations in the puma issue seem to have made progress and targeted the real issue having to do with Net::HTTP::Persistent timeouts under POST. Going to try checking this in and see what Travis says. |
by lowering POST timeouts to 1. From Net::HTTP::Persistent history.txt: "Reducing the idle timeout is preferred over setting #retry_change_requests to true if you wish to avoid the "too many connection resets" error when POSTing data."
Hmmm, now 2.3.0 passes, but 2.2.4 fails and jruby/2.0.0 seem to be failing for rubygems connectivity issues? Weird. |
Ha! Rebuilding succeeded without any code change, except for ruby 2.0.0 and jruby which still seem to be failing because @rogerleite is this normal for this project? Let me know if I'm obsessing too much. :) I'll run it again later and see if the bundler issue resolves itself. |
some of the http clients tested) no longer supports Ruby 2.0.0 and breaks Travis CI under 2.0.0 test. In practice, not all http clients have this dependency, so I didn't want to put this restriction in the httpi.gemspec. Other options are to remove 2.0.0 from travis.yml and update the httpi.gemspec to require ruby >= 2.1.0, but this requires more discussion.
1 similar comment
VICTORY! |
@rogerleite is there anything else I need to do to get this into the next release? Thanks! |
fixes savonrb/savon#819