GitHub yearly commit activity badge is flaky

[paulmelnikow]

Are you experiencing an issue with...

• shields.io

🪲 Description

This badge shows invalid.

🔗 Link to the badge

• https://img.shields.io/github/commit-activity/y/badges/shields.svg

These work:

• https://img.shields.io/github/commit-activity/4w/badges/shields.svg
• https://img.shields.io/github/commit-activity/4w/eslint/eslint.svg
• https://img.shields.io/github/commit-activity/y/eslint/eslint.svg

💡 Possible Solution

Not sure! Refactoring the service is probably a good start!

[paulmelnikow]

Amazing. It was showing "invalid" a moment ago. 🤦‍♂️

[chris48s]

There's something subtle going on here.. try it on a repo that hasn't been queried before it'll say invalid the first time. Then give it a moment and add ?foo=bar to cache-bust it and it will work.

[paulmelnikow]

Yea… I noticed that switching it to .json works too.

[calebcartwright]

Doing some issue cleanup here to help facilitate a more focused discussion should anyone be interested in digging into this one. As a reminder to folks, please refrain from the update requests and "me too" type of comments; those aren't particularly helpful and just add noise.

There's two separate circumstances that can result in folks seeing the badge show an invalid message:

1. Your target repository is too new for your target time period, and you just need to wait a bit for the data to start showing up in the GitHub API
2. The badge in long-standing projects will randomly on occasion change from showing an expected message to showing invalid, without any explanation.

This issue is really focused on that second use case. It's true that in either case one can tweak the badge url which busts the cache, and that'll often work because the underlying issue is very temporal in nature. If the upstream GitHub API issue has resolved then the badge will be back, but if not the invalid message will persist. However, trying to bust the cache isn't a necessary step, as the badge gets corrected fairly quickly on its own (hence the reference to the flaky behavior).

We currently fetch the commit data from GitHub's commit activity v3 API and the root cause for the temporary invalid message on badges is most likely that we temporarily get an unexpected HTTP response code from that endpoint.

What would be helpful for anyone interested in assisting with the resolution of this issue:

• For existing/working badges (second use case from above) that suddenly see an invalid message, check the corresponding API response for your project and capture/share the results here (or ping us in our Discord server if you'd prefer). The API call would like something like this, with your owner and repo name replaced: https://api.github.com/repos/badges/shields/stats/commit_activity
• Evaluate whether the commit data is readily available via GitHub's v4 API (GraphQL based), and share any findings, suggested queries, etc. and consider submitting a PR to refactor the existing service providing this badge to use the v4 API instead. We have various other examples of such migrations for reference and happy to help anyone interested

[chris48s]

Evaluate whether the commit data is readily available via GitHub's v4 API (GraphQL based)

Good thinking 👍 This was not an option when this issue was first raised but I reckon this is probably the most likely path to a solution.

I think the /stats/commit_activity endpoint is probably slow to generate if the stats aren't cached on Github's side. If we can issue a more constrained query via the GQL api then maybe we can avoid the issue? If anyone is interested in helping resolve this, then I suspect that is the best line of attack.

[calebcartwright]

Finally managed to capture this in action. This occurs when GitHub is responding to us with a 202 status code and an empty body.

I'm going to take a look at a graphql query for this, and if it looks like too big a hurdle to convert in the near future then I'd suggest we investigate checking for the 202 specifically and set the message to something like github processing accordingly