Incorrect coverage badge

[dkubb]

On my project https://github.com/dkubb/ice_nine I have a coveralls badge and it shows 55%, yet when I click through and look at the stats they all show 100%.

I double checked using curl to see if it was some kind of browser cache issue, and this is what I got:

$ curl -I "https://coveralls.io/repos/dkubb/ice_nine/badge.png?branch=master"
HTTP/1.1 302 Found
Server: cloudflare-nginx
Date: Wed, 03 Dec 2014 18:39:07 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie: __cfduid=d00e622833760d2a2ecd08144e10face61417631947; expires=Thu, 03-Dec-15 18:39:07 GMT; path=/; domain=.coveralls.io; HttpOnly
Status: 302 Found
Location: https://s3.amazonaws.com/assets.coveralls.io/badges/coveralls_55.png
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: no-cache
X-Request-Id: ef8b2578b914bfebfdb77a26fdfc5213
X-Runtime: 0.035249
X-Rack-Cache: miss
X-Powered-By: Phusion Passenger 4.0.42
X-Powered-By: cloud66
CF-Cache-Status: MISS
CF-RAY: 1931e29a48620508-SEA

As you can see requests for this badge are incorrectly redirected to the 55% badge.

Is there some kind of caching problem on your end that has the coverage amount "stuck" at 55%? Or is there something else I can do on my end to display the correct badge amount?

[techjeffharris]

I have this same problem as well, only 59% for me, though I have seen it jump after increasing coverage.. It seems that a few moments after a Travis CI build, the badge updates (after a few refreshes), then after a short amount of time, it goes back to 59% :(

https://github.com/adminion/friends-of-friends

[fattenap]

Hi,

I'm also experiencing problems with updates. I received the initial update but the badge hasn't updated since. It's been a few days now.
https://coveralls.io/r/entrendipity/astarisx?branch=master

Thanks

[jmthomas]

Same here. Coverage is at 91.37 (green!) but badge says 89.34 (yellow!). https://coveralls.io/r/BallAerospace/COSMOS

[evoskuil]

Where is the branch=master parameter documented? This technique works for Travis-CI, but not for Coveralls. I've tried this with bogus branch names and it makes no difference, which would explain the issues above. But I can't find documentation on branch specification.

[evoskuil]

Apart from the branch issue mentioned above, it looks like GitHub is messing up the icons.

This is a Travis image embedded in a page:

<a href="https://travis-ci.org/evoskuil/libbitcoin">
<img
src="https://camo.githubusercontent.com/637e6807fc018c7d71efabf1e9fd20715017498c/68747470733a2f2f7472617669732d63692e6f72672f65766f736b75696c2f6c6962626974636f696e2e7376673f6272616e63683d6d6173746572"
alt="Build Status"
data-canonical-src="https://travis-ci.org/evoskuil/libbitcoin.svg?branch=master"
style="max-width:100%;">
</a>

This is a Coveralls image in the same page.

<a href="https://coveralls.io/r/evoskuil/libbitcoin">
<img 
src="https://camo.githubusercontent.com/a38411cf4340c095eae7c9b6d2c28d60215ff3b7/68747470733a2f2f636f766572616c6c732e696f2f7265706f732f65766f736b75696c2f6c6962626974636f696e2f62616467652e737667"
alt="Coverage Status"
data-canonical-src="https://coveralls.io/repos/evoskuil/libbitcoin/badge.svg"
style="max-width:100%;">
</a>

Apart from the inability to target the master branch, they are basically the same. But the src attributes are defined by GitHub. The img elements are created from this markdown by GitHub:

[![Build Status](https://travis-ci.org/evoskuil/libbitcoin.svg?branch=master)](https://travis-ci.org/evoskuil/libbitcoin)

[![Coverage Status](https://coveralls.io/repos/evoskuil/libbitcoin/badge.svg)](https://coveralls.io/r/evoskuil/libbitcoin)

The src tags are hosted at camo.githubusercontent.com. These are a server cache of what is returned by Travis and Coveralls when the markdown is rendered as HTML.

Hitting the URLs directly returns the a redirect to the correct images:

https://coveralls.io/repos/evoskuil/libbitcoin/badge.svg

currently (and correctly) redirects to:

https://s3.amazonaws.com/assets.coveralls.io/badges/coveralls_87.svg

Yet the presentation is the cached image from GitHub:

https://camo.githubusercontent.com/a38411cf4340c095eae7c9b6d2c28d60215ff3b7/68747470733a2f2f636f766572616c6c732e696f2f7265706f732f65766f736b75696c2f6c6962626974636f696e2f62616467652e737667

Which is the "coverage unknown" gray image.

The redirect is as follows:

HTTP/1.1 302 Found
Server: cloudflare-nginx
Date: Fri, 15 May 2015 04:23:43 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie: __cfduid=[snip]; expires=Sat, 14-May-16 04:23:43 GMT; path=/; domain=.coveralls.io; HttpOnly
Status: 302 Found
Location: https://s3.amazonaws.com/assets.coveralls.io/badges/coveralls_87.svg
X-UA-Compatible: IE=Edge,chrome=1
Cache-Control: no-cache
X-Request-Id: 9585be90920c071ceea532cc08505fa6
X-Runtime: 0.033715
X-Rack-Cache: miss
X-Powered-By: Phusion Passenger 4.0.47
X-Powered-By: cloud66
CF-Cache-Status: MISS
CF-RAY: 1e6c11af89651bc7-SEA
Content-Length: 134

<html><body>You are being <a href="https://s3.amazonaws.com/assets.coveralls.io/badges/coveralls_87.svg">redirected</a>.</body></html>

This is a 302 temporary redirect (i.e. not a 301) with a Cache-Control: no-cache directive. So GitHub should not be returning the image to represent the element without retesting the URL.

It is odd however that the Travis image works properly, and it is returning a 301 (permanent redirect).:

https://travis-ci.org/evoskuil/libbitcoin.svg?branch=master

returns:

HTTP/1.1 301 Moved Permanently
Server: Cowboy
Date: Fri, 15 May 2015 04:29:42 GMT
Connection: keep-alive
Content-Type: text/html;charset=utf-8
Location: https://api.travis-ci.org/evoskuil/libbitcoin.svg?branch=master
Content-Length: 0
Via: 1.1 vegur

Seems backwards, but Coveralls may want to do what Travis is doing.

[tfausak]

This is also affecting a repository I contribute to. The coverage is 99.69%, but the badge shows 95%. This is for build 1266.

> http -p h https://coveralls.io/repos/orgsync/active_interaction/badge.svg | 
  grep '^Location: '
Location: https://s3.amazonaws.com/assets.coveralls.io/badges/coveralls_95.svg

[dkubb]

Apart from the branch issue mentioned above, it looks like GitHub is messing up the icons.

@evoskuil The badge amount is even messed up on coverall's own pages. See for example on https://coveralls.io/github/dkubb/ice_nine where the right hand side shows 81%, and everywhere else shows 100%.

This looks like some kind of caching problem. It's been an ongoing issue for the past year. :(

[uklance]

This issue is also happening on my github page https://github.com/uklance/tiny-ioc
Coverage shows as 90% but click through and it shows 91%

NOTE: I also have travis and bintray badges which don't have the same problem. I suggest inspecting the http responses to see the diferences, I'm guessing it's response cache headers.

Travis Image URL (as transformed by github)

https://camo.githubusercontent.com/4831c4d38cef02e53dd5a8d47b7f68be08f08726/68747470733a2f2f7472617669732d63692e6f72672f756b6c616e63652f74696e792d696f632e7376673f6272616e63683d6d6173746572

Travis response headers

Accept-Ranges bytes
Age 0
Cache-Control no-cache
Connection keep-alive
Content-Length 724
Content-Type image/svg+xml
Date Thu, 30 Jun 2016 08:22:47 GMT
Expires Thu, 30 Jun 2016 08:22:47 GMT
Last-Modified Thu, 30 Jun 2016 07:43:05 GMT
Server github-camo (12274939)
Strict-Transport-Security max-age=31536000; includeSubDomains
Timing-Allow-Origin https://github.com
Via 1.1 varnish
X-Cache-Hits 0
X-Fastly-Request-ID ?????????????
X-Frame-Options deny
X-GitHub-Request-Id B91F1325:2F46:188F1B1:5774D6D6
X-Served-By cache-lhr6345-LHR
X-Timer S1467274967.075710,VS0,VE182
X-XSS-Protection 1; mode=block
content-security-policy default-src 'none'; img-src data:; style-src 'unsafe-inline'
x-cache MISS
x-content-type-options nosniff

Coveralls Image URL (as transformed by github)

https://camo.githubusercontent.com/74021b18347cc0aea4d4cfc69f099ced1cead0d2/68747470733a2f2f636f766572616c6c732e696f2f7265706f732f756b6c616e63652f74696e792d696f632f62616467652e7376673f6272616e63683d6d6173746572

Coveralls Response Headers

Age 1205
Cache-Control no-cache
Connection keep-alive
Date Thu, 30 Jun 2016 08:26:35 GMT
Timing-Allow-Origin https://github.com
Via 1.1 varnish
X-Cache-Hits 1
X-Fastly-Request-ID ?????????
X-Served-By cache-lhr6321-LHR
X-Timer S1467275195.131755,VS0,VE0
x-cache HIT

[marcusreese]

Same problem.
https://github.com/marcusreese/cogz/blob/master/README.md badge says coverage is 85%.
When I click through to https://coveralls.io/github/marcusreese/cogz it says I've been 100% for 11 days now.

[mkopylec]

I have the same issue in my project https://github.com/mkopylec/charon-spring-boot-starter
The bagde image on GitHub is showing 93% and the real coverage is 94%.

[coltonlw]

Same problem, waited over 12 hours coverage badge still not updated

https://github.com/scitran/core/

[nolanlawson]

Hitting this in PouchDB as well: https://coveralls.io/github/pouchdb/pouchdb

[jazzycamel]

Same issue for my repo (https://github.com/jazzycamel/pushy). Badge currently say 0% when I have 98% coverage!

[airstruck]

Just happened to me in the last day or two, badge shows 88% but coverage is at 100%.

https://github.com/airstruck/knife

@jazzycamel looks like yours is working now, did you do anything to fix it?

[chulkilee]

Github caches images. Can someone from coveralls make sure coverall sets all response headers correctly per github/markup#224, probably along the whole response redirections?

[stale]

This issue has been automatically marked for closure because it has not had recent activity. It will be closed if no further activity occurs. If your issue is still active please add a comment and we’ll review as soon as we can. Thank you for your contributions.