action: query the Go proxy for CUE versions #13
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We believe that the cause of intermittent GitHub API 403 responses,
which are now exposed to the Action consumer and not masked, is that
this Action doesn't use a GITHUB_TOKEN (even when provided as an envvar)
to authenticate to the GitHub API.
Therefore, all our API requests are unauthenticated, which are nominally
rate-limited at a level which shouldn't affect any consumer. However,
they do affect consumers: ourselves, in testing, and also in
production.
We hypothesise that this is because GitHub-hosted GitHub Actions runners
are issued IP addresses from some shared pool, thus any requests "we"
make are counted against a rate limit that a previous user may have
already used up.
To get round this, this commit changes the Action's behaviour to use the
Go Proxy as the upstream decision maker for which CUE version is the
"latest", instead of querying the GitHub API for all versions and then
making this decision locally. This has the advantage of harmonising the
Action and the Go CLI's concepts of "latest".
An alternative would be to teach this Action's API requests to use the
GITHUB_TOKEN, if provided. This would have the downside of needing the
Action's consumers to provide this token in their workflows, so we avoid
this alternative for now.