The getManifestFromRepo function is utilized by several downstream actions such as setup-python and setup-go to download version manifests from a GitHub repository. However, when these Actions are run on GitHub Enterprise Server, the retrieval process counts against a 60 requests/hour/IP address rate limit imposed by GitHub.com. This limit is quickly exhausted if multiple runners share a single IP address.
Currently, the recommended solution is to manually add a GitHub.com access token to each action, which increases the rate limit. However, managing this at scale is cumbersome and impractical, particularly for Pull Requests from forks.
To improve the overall process, I suggest making this the default behavior of the getManifestFromRepo function. It would first attempt to retrieve the manifest via the content API to maintain existing behavior, and then fallback to the raw API if it encounters an error or rate-limit.
I am willing to propose a Pull Request for this change if there is interest.
The
getManifestFromRepofunction is utilized by several downstream actions such assetup-pythonandsetup-goto download version manifests from a GitHub repository. However, when these Actions are run on GitHub Enterprise Server, the retrieval process counts against a 60 requests/hour/IP address rate limit imposed by GitHub.com. This limit is quickly exhausted if multiple runners share a single IP address.Currently, the recommended solution is to manually add a GitHub.com access token to each action, which increases the rate limit. However, managing this at scale is cumbersome and impractical, particularly for Pull Requests from forks.
A more effective solution would be to download the manifest via the
rawendpoint (e.g., https://raw.githubusercontent.com/actions/go-versions/main/versions-manifest.json). Unlike the content API, therawendpoint does not impose rate limits, eliminating the need for an access token.I have already implemented this approach for
setup-python(see: https://github.com/actions/setup-python/pull/766) and proposed it forsetup-go(see: https://github.com/actions/setup-go/pull/496).To improve the overall process, I suggest making this the default behavior of the
getManifestFromRepofunction. It would first attempt to retrieve the manifest via the content API to maintain existing behavior, and then fallback to therawAPI if it encounters an error or rate-limit.I am willing to propose a Pull Request for this change if there is interest.
Code Snippet n/a
Additional Information
For further context, see the issue discussing the rate limit challenge for
setup-python: https://github.com/actions/setup-python/issues/756