Rate limiting from Github when running fastly compute serve

[GeeWee]

Version

Locally:

Fastly CLI version v4.5.0 (c56025c)
Built with go version go1.18.9 linux/amd64
Viceroy version: viceroy 0.3.2

Although this happens in CI with the same version fetched using https://github.com/fastly/compute-actions

What happened

Some of our tests fail and are flaky with the following error class:

ERROR: error fetching latest version: GET https://api.github.com/repos/fastly/viceroy/releases/latest: 403 API rate limit exceeded for 65.52.35.2. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.) [rate reset in 10m33s].

This seems similar to #538 and #524 , and seems to suggest being fixed in #488 although that clearly doesn't seem to be the case.

I understand that this seems to hapen because fastly compute server fetches viceroy on the first invocation, and it does so in an unauthenticated manner - sometimes leading to rate limiting like this.

Potential solutions

None of the other issues have solutions that are possible to use. One of them relies on fetching viceroy manually which I would prefer not to do, as it explicitly says in Viceroy we should be using the CLI. The other one relies on mounting docker volumes persistently - a capability that's not present in Github Actions.

With that in mind - here's some solution suggestions:

Have compute-actions fetch viceroy

I'm actually a little surprised that using compute-actions doesn't also fetch viceroy - I would expect that I would after calling setup (and fetching the CLI) be able to use everything without further downloads.
compute-actions also allows me to use a github token to avoid rate-limiting of the Github API. If the setup-action there did this work, I would be able to avoid the rate-limiting

Use a non-rate limited infrastructure

Generally we've struggled quite a bit with github rate limiting errors in different context (such as fetching the CLI, and now, fetching viceroy). Perhaps it might make sense to host the binaries somewhere other than github where you can handle rate-limiting yourself rather than relying on Github. I don't expect this will happen, but it is a potential solution.

Document a github token parameter or environment variable

It would also be acceptable to just document whether or not you accept an env variable as the github token, such as GH_TOKEN that would then be picked up by the fastly CLI.
Perhaps it would also make sense to write that as part of the rate-limiting error message. Currently it's extremely opaque and you actually have to understand quite a bit of the fastly internals to understand that it's actually github rate limiting you, and github you need to authenticate with.

[Integralist]

Hi @GeeWee

Thanks for opening this issue, we've actually been working on a solution to this problem here:
#739

From what I can tell it most closely resembles your "Use a non-rate limited infrastructure" suggestion.

It's ready to be merged but I'm out on PTO until the new year, and so getting a new CLI release published with that PR change set is one of my first priorities upon my return.

[GeeWee]

Hey!

Ah, that's great news. That does seem like it would solve at least part of the issue. If the binaries are still being fetched from github (which it seems like based on a quick skim of the PR, although I could be wrong), there might be rate-limiting on that part? I'm unsure when github applies rate-limiting, if it's only for querying latest releases or also for fetching the binaries.

Either way seems like it'll be a good improvement, and I'm excited for it. Enjoy your PTO!