API rate limit exceeded about setup-go

[mvdan]

Hmm, I still sometimes run into API rate limit errors with versions like 1.13. It fails with no helpful error when I specify 1.13.0, so I think it's not doing the same as 1.13.x.

It should be possible to download a specific version of Go with zero GitHub API calls, as one can download Go straight from golang.org. It's even possible to list all released versions via JSON without even hitting GitHub: https://golang.org/dl/?mode=json&include=all

[subosito]

@kjk @mvdan @damccorm I've updated API call to use the golang-dl one. I didn't know about this.

[mvdan]

Friendly ping @damccorm - any chance this could get attention soon? Actions can't be used as CI for Go until this is fixed, since builds start failing after just a dozen or so builds. The golang.org approach suggested above should work, and there's even a PR ready :)

[mvdan]

Big thanks to @hfaulds for taking care of merging the PR! I think this can be closed for now. I'll shout if I see these flakes again.

[damccorm]

Huh, interesting - 2 questions:

1. Are you able to share your repo where you're seeing this by chance? I can't get a repro
2. Are you only seeing it when running this action? Or is it a more general problem?

[Harmon758]

1. I was getting it consistently Friday afternoon, but waiting 30 min. - 1 hour and re-running the job (through Re-run all checks) sometimes worked. Since then, I've re-ran all the jobs that failed at the time, but I just now encountered the error again: https://github.com/Harmon758/Harmonbot/runs/203474041
2. That repository uses actions/setup-python as well, and I haven't encountered this issue with it.

[damccorm]

Interesting - I'm guessing its this call that's getting rate limited, I'm not really sure why though, and haven't seen this happen elsewhere.

I'll try to dig in a little more and figure out what exactly is happening here

[kjk]

Just an idea: data returned by https://api.github.com/repos/golang/go/git/refs/tags doesn't change often so it could be stored directly in this repo and updated once a day via cron job (via GitHub Action Workflow, of course).

I did something like that so you can use that as inspiration:

• https://github.com/kjk/blog/blob/master/.github/workflows/update_from_notion.yml
• https://github.com/kjk/blog/blob/master/s/ci_update_from_notion.sh

It's quite simple: a daily cron job updates some files in the repo and if they change, it checks them in.

A bonus of such change is that it would speed up the action (by removing an http request).

[damccorm]

I like the idea here in theory and see definite advantages, I think it might create a bit of a headache with publishing though - e.g. do we bump our v1 tag every time this gets updated? Do older releases not work with newer versions of Go? - and I'm more inclined to fix this from a rate limiting side (since I don't think we should be getting rate limited here).

It also could create a weird situation where 12.x resolves to one Go version for v1.0.0 of this action, but to a different Go version for v1.1.0 of the action which seems non-ideal.

[pelletier]

FYI, I am seeing this as well, trying to setup Github Actions on a public repo: https://github.com/pelletier/go-toml/pull/294/checks?check_run_id=204074095

Started happening after ~1h of working on it.

[kjk]

Probably relevant: the ip address hitting this limit is 199.7.166.17 which belongs to MacStadium.

I assume GitHub uses MacStadium for running OSX jobs and it seems they're all behind the same proxy which is why they are hitting GitHub limit.

So if GitHub has such capability, you should whitelist that IP address.

[nathany]

Also seeing this error here after adding macOS to the build matrix.

strategy:
      matrix:
        os: [ubuntu-latest, macOS-latest, windows-latest]

It also appears to have cancelled my Windows and Linux builds?

[Bios-Marcel]

I experienced this too: https://github.com/Bios-Marcel/cordless/runs/208451699

Same IP, same symptoms. Depending on what the rate limit is, might it be possible to just delay the download instead of failing?

[kjk]

Another option would be to attribute the call not to anonymous user but to a given GitHub user.

Actions already provide GITHUB_TOKEN secret of the repo's owner. It's just a matter of plugging it into that API call.

It might not be possible to just access it from the action but it would be possible to define github-token argument to the action, use it if provided and document that to avoid this rate limit, the user can provide it as:

with:
    github-token: ${{ secrets.GITHUB_TOKEN }}

[mvdan]

I think a reasonable temporary solution is to specify exact Go versions like 1.12.9 instead of 1.12.x. This shouldn't require GitHub API calls, so it shouldn't have any rate limit issues.

[kjk]

+1 to https://golang.org/dl/?mode=json&include=all
It looks like using it would eliminate the rate-limited api call

[Bios-Marcel]

Would be nice to get this merged fast and push a minor release :D

[andreynering]

I'm also facing this issue. If this is already fixed, it'd be nice to have a release so people benefit of this.