coveralls .svg shield broken

[CleanCut]

I've put up both the coveralls .png and .svg shield here:

https://github.com/CleanCut/green

The .svg shield eventually comes up as a broken link. If you actually put the .svg url in your browser, it eventually renders a "vendor:unresponsive" shield.

I tried both the exact format listed at shields.io and at https://coveralls.io/r/CleanCut/green with identical results.

What's broken? What can I fix? I would much rather use the .svg versions through shields.io for consistency than have the coveralls shield be a different-looking .svg.

[seanlinsley]

I'm seeing the same thing on my project:

[CleanCut]

@seanlinsley I'm glad to know it's not just me!

[CleanCut]

It's possible this is actually a coveralls issue. Just in case, I also created an issue with them here: lemurheavy/coveralls-public#304

[espadrine]

Whatever yields the "vendor:unresponsive" badge is not our fault: it appears when we call an external server and wait for an answer for more than 20 seconds.

Unfortunately, GitHub's camo registers a failed answer way before those 20 seconds are up.

The best answer I can give: ask Coveralls to help with this issue.
I asked Coveralls for help there: https://twitter.com/espadrine/status/468428086959407104.

[nickmerwin]

Hi @espadrine, here's what I'm seeing when loading the badge url from our servers:

time curl -I https://coveralls.io/repos/gregbell/active_admin/badge.png?branch=master
HTTP/1.1 302 Found
Server: cloudflare-nginx
Date: Mon, 19 May 2014 19:36:37 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie: __cfduid=d9b0afbf02d2ab7a868a0288c4b3230c11400528197528; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.coveralls.io; HttpOnly
Status: 302 Found
Location: https://s3.amazonaws.com/assets.coveralls.io/badges/coveralls_83.png
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: no-cache
X-Request-Id: c458c8ec52542c1a13db5c1aa030cd0d
X-Runtime: 0.042989
X-Rack-Cache: miss
X-Powered-By: Phusion Passenger 4.0.41
X-Powered-By: cloud66
CF-Cache-Status: MISS
CF-RAY: 12d2be9283de09c4-ORD


real    0m1.328s
user    0m0.031s
sys 0m0.007s

And from shields.io:

time curl -I http://img.shields.io/coveralls/gregbell/active_admin.svg
HTTP/1.0 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Content-Type: image/svg+xml;charset=utf-8
Date: Mon, 19 May 2014 19:36:55 GMT
X-Cache: MISS from 172.19.134.2
X-Cache-Lookup: MISS from 172.19.134.2:3128
Via: 1.0 172.19.134.2:3128 (squid/2.6.STABLE14)
Connection: close


real    0m25.551s
user    0m0.005s
sys 0m0.004s

Could you help me understand the time discrepancy there?

[espadrine]

@nickmerwin I can only guess that it has to do with rate limiting on Coveralls' side. I have yet to receive a statement from them. When I run the same Shields.io server code from my laptop, those issues disappear.

[nickmerwin]

@espadrine we're not doing any rate-limiting. Do you mean you don't see the 25s delay from your local server?

[espadrine]

To be more specific, here's what the logs show:

2014-05-19T22:15:15.456112+00:00 heroku[router]: at=info method=GET path=/coveralls/gregbell/active_admin.svg host=img.shields.io request_id=1386df23-8fb5-4831-9ddc-25b1bbeaee55 fwd="92.128.18.151" dyno=web.1 connect=4ms service=25012ms status=200 bytes=608

(The 25012ms indicates that the request took 25 seconds to process.) If we didn't have the "vendor unresponsive" badge, Heroku would kill the request after 30 seconds. Back when we started, everything was fine for a month. Then, after another month, I started noticing that the requests took longer, about 10 seconds. It became a problem the next month, when it started taking more than 30 seconds half of the time. That's when I introduced the "vendor unresponsive" badge. I added a cache more recently, to show the latest data we got from the vendor's servers when we successfully got something in the past. The code to perform the request to the Coveralls servers has barely changed since we started.

I don't see any delay from my laptop running the server code, nor from another Heroku server running the same code: http://b.adge.me/coveralls/gregbell/active_admin.svg.

[nickmerwin]

@espadrine ok, I'm beginning to suspect CloudFlare is erroneously labeling shields.io as a threat. I've disabled all threat protection but it doesn't seem to have helped. Would it be possible for you to try this on Heroku so we can see the response headers?

heroku run bash -a ...
time curl -IL https://coveralls.io/repos/jekyll/jekyll/badge.png?branch=master

Edit: Another thing to try would be the non-CloudFlare enabled subdomain:
http://direct.coveralls.io/repos/jekyll/jekyll/badge.png?branch=master
(it's non-SSL since CF is handling our SSL)

[dougwilson]

P.S. would it be too much to ask to lower the timeout such that GitHub's proxy will display the "vendor unresponsive" badge, at least? :(

[jescalan]

Just want to throw in a big 👍 and thanks for working on this issue! Have noticed broken coveralls badges in a bunch of repos as well, and stoked that this is being looked at. Let me know if I can help in any way!

[espadrine]

@nickmerwin Running that curl on a heroku run bash session yields the result pretty much instantly. Then again, it might be seen as a distinct instance that can access the same directory content, not sure how heroku run bash works…

Can I try to use direct access on production? Is there a trade-off there?

@dougwilson I'm curious what GitHub's timeout is? How low should I lower the timeout?

@Jenius Thanks!

[seanlinsley]

Then again, it might be seen as a distinct instance that can access the same directory content, not sure how heroku run bash works…

Yeah, that's the case. heroku run creates a brand new instance for the duration of your command. Docs: https://devcenter.heroku.com/articles/one-off-dynos

[dougwilson]

@espadrine it look like their timeout is 10s

[nickmerwin]

@espadrine I've opened a PR that changes the Coveralls apiUrl to use badge.coveralls.io which will bypass CloudFlare:

#183

Hopefully that will do the trick!

[dougwilson]

It looks like they are working again :D

[nickmerwin]

@dougwilson yes it does! Not sure where the fix originated yet, but we may be able to close this issue.

🍻

[CleanCut]

I don't see any fix for my badge. On https://github.com/CleanCut/green the .png still shows up and the .svg is still broken.

[nickmerwin]

@CleanCut hmm the svg is showing up for me:

Maybe browser cache?

[CleanCut]

@nickmerwin Must have been. This morning it's working for me now. Thanks!!

[seanlinsley]

Hmm, but #183 hasn't been merged. Nothing has changed in terms of behavior, I thought.

[jescalan]

Yeah, I'm seeing it still broken on all my repos...

[dougwilson]

Yea, the badges are not loading again. I guess it was just momentarily fixed by whatever mechanism is causing the problem in the first place.

[CleanCut]

Okay, ya, this is weird. This morning at home it was working. Now that I am at work, it is broken again.

[espadrine]

It might be due to an IP change on Heroku's part?

[nickmerwin]

@espadrine definitely possible, but the #183 change should bypass that issue altogether; were you able to take a look?

[espadrine]

@nickmerwin Yep; the patch doesn't cleanly work, but I'm fixing it, and I'll put it live.

[jescalan]

Update here once this has been deployed so we can test? Thanks again guys for the hard work here 👬

[espadrine]

It should be live right now.

[nickmerwin]

Great!
@CleanCut https://github.com/CleanCut/green looks good!

[jescalan]

Oh beautiful, yup looks like this is working great. Whoo! 🎉

[nickmerwin]

Thank you @espadrine looks like we're golden.

[espadrine]

Thank you all!

[CleanCut]

@nickmerwin Yep! It works for me! Thanks, everyone!