CI status for plugin list in README.md is causing api rate limiting

[clintmod]

Describe the Bug

CI status for plugin list in README.md is causing api rate limiting. The current workaround is to press escape when the page is loading.

Steps to Reproduce

1. Browse to https://github.com/asdf-vm/asdf-plugins
2. Wait until the page finishes loading
3. Try to browse a different url on github.com
4. Notice api rate limit exceeded message

Expected Behaviour

Browsing to the README shouldn't cause api rate limiting

Actual Behaviour

An error is displayed with api rate limit exceeded message

Environment

Chrome on Macos

[thingythekid]

This was causing a problem for me too, so I've created a pull request (/pull/881) to remove the CI statuses from the README.md file.

If there's a better way to solve this problem I'm open to input.

Sorry if I caused anyone to get spammed while I tried to wrestle git into using the correct identity for the commit!

[jthegedus]

@clintmod Thanks for raising. While CI status is not a perfect measure of whether a plugin is in an expected working state or actively developed, it is the only useful metric this repo provides directly.

I am not sure removing the status as in #881 is the "best" option to take. Perhaps we can compute the status on a weekly or daily basis and store the state as a static badge in that column of the README. I am open to alternatives here, but don't particularly want to invest significant engineering time into a complex solution.

[thingythekid]

@jthegedus Thanks for clarifying the purpose of the CI status list, that makes sense.

Were you thinking of having some kind of hosted image cache to achieve this, or some other approach?

Maybe a low-effort interim fix could be to have two copies of the plugin list:

1. The copy in README.md, without CI statuses, and
2. A copy in a second file, maybe PLUGIN_STATUSES.md, that includes CI statuses.

Maybe README.md could include a link to the second file with a warning about the rate limit.

While this might mean maintaining two copies of the plugin list, it would mean that users navigating to the project page could search it for plugins they're interested in without being rate limited.

[jthegedus]

Were you thinking of having some kind of hosted image cache to achieve this, or some other approach?

Not quite. I was thinking a weekly cron GitHub Action that fetches each build status and just puts a ✅ or ✖️ depending on the status at the time the weekly job ran. That way, once a week the README would refresh with the status checks at that time. Then a note in the README about statuses being stale. The checkmark/X could link to the build status. And while we're at it would could fetch some other repo metadata to store, like repo age. We could also run the plugin test command for each plugin as well with another column listing that it passed our automated CI check to execute the --version or --help command.

There's a lot we could do here, but mostly I don't want to invest too much engineering effort (mine or others) in this plugin repo as it is not a model we enjoy maintaining or one that gives the best user experience for plugins.

Happy to accept contributions, but please don't invest too much time with too much complexity here. This repo exists to save people typing URLs and discoverability, but those two reasons are not intrinsically linked.

[thingythekid]

@jthegedus

There's a lot we could do here, but mostly I don't want to invest too much engineering effort (mine or others) in this plugin repo as it is not a model we enjoy maintaining or one that gives the best user experience for plugins.

That's understandable.

Happy to accept contributions, but please don't invest too much time with too much complexity here. This repo exists to save people typing URLs and discoverability, but those two reasons are not intrinsically linked.

Looking back over this thread, the severity of this issue hasn't been made clear; this issue prevents users who aren't logged in from using this repo to discover plugins, and generally prevents them from using GitHub for several minutes after they visit this repo for the first time.

If you're not logged in, the rate limit means that you can't navigate to any of the plugin repos after you load the page for this repo. To make this worse, you can't navigate to the issues list for this repo to see what the problem is.

That's how I ran into the problem myself; I tend to use GitHub without being logged in, so the site suddenly stopped working after I navigated to the plugins repo.

Basically, what I'm saying is I think it's important to favour a quick interim solution here so as to avoid preventing innocent users from browsing GitHub.

[clintmod]

It actually restricts so you can't do anything on github for a minute or two.