hstove / issue_stats

Analyze and compare how long it takes for Github issues to be closed.
issuestats.com
MIT License
184 stars 13 forks source link

Badges on Project Readme and linked IssueStats website differ #20

Closed forki closed 8 years ago

forki commented 9 years ago

We are using issuestats for https://github.com/Microsoft/visualfsharp, but the badges in our readme show different stats than http://issuestats.com/github/microsoft/visualfsharp

image

image

we use the following snippet:

[![Issue Stats](http://issuestats.com/github/Microsoft/visualfsharp/badge/pr)](http://issuestats.com/github/microsoft/visualfsharp)
[![Issue Stats](http://issuestats.com/github/Microsoft/visualfsharp/badge/issue)](http://issuestats.com/github/microsoft/visualfsharp)

// cc @latkin @KevinRansom

latkin commented 9 years ago

ref https://github.com/Microsoft/visualfsharp/issues/165

hstove commented 9 years ago

It looks like this is because issuestats isn't setting the right cache headers, via https://github.com/github/markup/issues/224#issuecomment-33454537 . Working on a fix!

enricosada commented 9 years ago

@hstove i can repro the bug after

latkin commented 9 years ago

Yes, we still see this at https://github.com/Microsoft/visualfsharp

Is there any status update on a fix?

latkin commented 9 years ago

@hstove ping... We are about at the point of removing the badges since they don't provide any actual information.

latkin commented 9 years ago

@hstove we've removed issue stats from the Visual F# repo due to this ongoing problem. We'd be happy to add them back if/when it is addressed.

dmill-bz commented 8 years ago

@hstove it looks like you may be missing ETag headers still (from that same issue you posted). I'm experiencing the same issue as the others.

The assets may also need to include either an ETag or Expires header. Fastly's docs on Cache-Control say that no-cache means "re-validate before serving this content", but it doesn't specify what it does to "re-validate". I'm guessing it is re-validating, but there's no indication that the asset has changed, so it continues to serves the cached asset.

An ETag would be the biggest win, since it would guarantee that the cache gets refreshed when it changes, but still saves bandwidth.

hstove commented 8 years ago

Thanks @PommeVerte! I just added some code to add ETag and Last-Modified that should refresh when there is new data, and cache when not. Thanks for the tip, hopefully this is what Github's CDN needs!

dmill-bz commented 8 years ago

Thanks for the swift patch. Unfortunately this doesn't seem to work either which has me confused. A quick inspection in chrome shows the following (note that I did this check from issuestats.com as to avoid github's proxies)

Bellow are the headers of a badge that I know updates every now and then :

Cache-Control:max-age=3600, public, s-maxage=3600
Connection:Keep-Alive
Content-Disposition:inline; filename="downloads-722 -007ec6svg.svg"
Content-Type:image/svg+xml;charset=utf-8
Date:Wed, 07 Oct 2015 16:36:48 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.22 (Ubuntu)
Transfer-Encoding:chunked
X-Powered-By:PHP/5.3.10-1ubuntu3.17

Here's the header for the travis badge (can't see anything special):

Connection:keep-alive
Content-Length:0
Content-Type:text/html;charset=utf-8
Date:Wed, 07 Oct 2015 16:36:48 GMT
Location:https://api.travis-ci.org/PommeVerte/gremlin-php.svg?branch=master
Server:Cowboy
Via:1.1 vegur

Here's the coverall badge which updates regularly enough:

cache-control:must-revalidate, no-cache, no-store, private, max-age=0
cf-cache-status:MISS
cf-ray:231b14ba780214f7-CDG
content-type:text/html; charset=utf-8
date:Wed, 07 Oct 2015 16:46:14 GMT
etag:"b04626bf10527aa8ee678f9f4262ec19"
last-modified:Wed, 07 Oct 2015 16:19:05 GMT
location:https://s3.amazonaws.com/assets.coveralls.io/badges/coveralls_87.svg
server:cloudflare-nginx
status:302 Found
status:302 Found
vary:Accept-Encoding
version:HTTP/1.1
x-powered-by:cloud66
x-powered-by:Phusion Passenger Enterprise 5.0.14
x-rack-cache:miss
x-request-id:c2a3b68441e22fbce6c748479569e516
x-runtime:0.025760
x-ua-compatible:IE=Edge,chrome=1

I'm wondering if there isn't an issue with perhaps a proxy (with your provider?)? When I actually look and the ressource files in chrome I can find the badges for issuestats with the following headers (which are different from the ones in the image src)

cache-control:public, max-age=86400
cf-cache-status:HIT
cf-ray:231b06ec621514eb-CDG
date:Wed, 07 Oct 2015 16:36:48 GMT
expires:Thu, 08 Oct 2015 16:36:48 GMT
last-modified:Mon, 05 Oct 2015 10:05:50 GMT
server:cloudflare-nginx
status:304 Not Modified
vary:Accept-Encoding
version:HTTP/1.1

Hopefully this helps a bit.

dmill-bz commented 8 years ago

I'll wait until Thu, 08 Oct 2015 16:36:48 GMT to see if there's an update.

hstove commented 8 years ago

@PommeVerte it looks like the badges are synced, at least for https://github.com/PommeVerte/gremlin-php (http://issuestats.com/github/PommeVerte/gremlin-php) and a few other random repos I checked.

Hopefully its working!

dmill-bz commented 8 years ago

ahh indeed. Great!! Thanks for the hard work.

hstove commented 8 years ago

No problem! Thanks for pointing me in the right direction with ETag support.

@latkin , it looks like this issue is finally resolved, so if you want to put the issue stats badge back, it should work. Thanks!

ChristopherKing42 commented 8 years ago

Not currently working at https://github.com/ChristopherKing42/skynet/tree/patch-2

Issue Stats

http://issuestats.com/github/atemerev/skynet

hstove commented 8 years ago

Hm, I see a consistent PR-2 hours and Issue-1 day on your README, on issuestats.com, and on the badge you linked ^.

ChristopherKing42 commented 8 years ago

@hstove Oh, it was just my browser cache. It's correct now. Sorry for buggin' ya.