Travis badges seem to be broken

[patcon]

Not sure what's up, but here were some threads for anyone else coming across this:

gittip/www.gittip.com SVG definitely broken: http://img.shields.io/travis/gittip/www.gittip.com/master.svg

Nothing seems to have changes recently for Content-Disposition header from travis:
https://github.com/travis-ci/travis-api/blame/master/lib/travis/api/app/responders/image.rb#L10

(https.request headers aren't case-sensitive, are they?)
https://github.com/badges/shields/blob/master/server.js#L104

Reponse looks fine from travis:

vagrant@vagrant-ubuntu-precise-64:~/www.gittip.com$ curl -D - https://api.travis-ci.org/gittip/www.gittip.com.png -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Type, Cache-Control, Expires, Etag, Last-Modified
Age: 0
Cache-Control: no-cache
Content-Disposition: inline; filename="failing.png"
Content-Type: image/png
Date: Fri, 28 Feb 2014 20:55:12 GMT
Etag: "afb7d61719ef3158f07cd2376d3a794d"
Expires: Fri, 28 Feb 2014 20:55:12 GMT
Last-Modified: Fri, 28 Feb 2014 20:54:01 GMT
Pragma: no-cache
Server: nginx/1.5.7
Status: 200 OK
Strict-Transport-Security: max-age=31536000
Vary: Accept,Accept-Encoding
X-Accepted-Oauth-Scopes: public
X-Content-Digest: 7695db30b4e7adea1253503d8805a874d6f76032
X-Endpoint: Travis::Api::App::Endpoint::Repos
X-Oauth-Scopes: public
X-Pattern: /:owner_name/:name
X-Rack-Cache: miss, store
Content-Length: 1247
Connection: keep-alive

[espadrine]

@patcon It seems from looking at the logs that Travis sometimes takes more time than Heroku likes, especially with specified branches. Heroku kills every request that takes more than 30 seconds to process and returns an error. Such a timeout doesn't happen that often, but even once a day is too often.

Our best bet is #134, which will return a cached version when it takes more than 10 seconds to proceed the request.

[patcon]

Thanks for the response man, but just to clarify, it wasn't an isolated incident. I saw dead badges on over a dozen other github projects over the course of last night, and every time I checked it was because they were using shields.io :(

Do you have metrics on the number of pageviews where badges can't be rendered? Is that something you need? Just wondering how I might help get some perspective on the scope of this, if we need that :)

EDIT: And still dead by the way: https://github.com/badges/shields#shields---
Sorry if you knew this, but your response seemed like you were speaking of it as a past event.

EDIT2: Ah nevermind... github caches...

[patcon]

Hm. Seemed perhaps github won't cache https images:
github/markup#224

Would that be helpful for us?

[patcon]

Or perhaps it's that the failed image doesn't send Cache-Control headers?

Also: github/markup#224 (comment)

[espadrine]

I tweeted to them to know whether we are rate-limited (if we are, we weren't before). From what I see, it is never a systematic request timeout, and it is only from shields' Heroku server instance. Also, that request timeout is set at 30 seconds.

[feross]

@patcon that was a long time ago. github now caches https images too.

[espadrine]

It seems that this is less of an issue now.

[seanlinsley]

Yep, it's been working well for me for a while now.

[amcgregor]

I'll note here that the Travis badges are broken for my first project to make use of this nifty service. They aren't just broken on Github's read-me display:

• The GitHub Project
• Its Python Package Index Page
• Likely here, too:

The last few test runs have been successful on both release (master) and development branches.

[olivierlacan]

@amcgregor Can you open a separate issue for this, the badges aren't "broken", they're reporting erroneous information which is a different problem than this issue was originally about and a bit more interesting actually. Thanks. :-)