fallback to un-ratelimited "raw" endpoint for `getManifestFromRepo`
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 5.9k
- Forks
- 1.8k
- PR merge metrics
- No merged PRs in 30d
Description
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.
A more effective solution would be to download the manifest via the raw endpoint (e.g., https://raw.githubusercontent.com/actions/go-versions/main/versions-manifest.json). Unlike the content API, the raw endpoint 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 for setup-go (see: https://github.com/actions/setup-go/pull/496).
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.
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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in packages/tool-cache/src/tool-cache.ts at getManifestFromRepo, referenced around lines 589-632, and inspect how the existing content API request handles errors and rate limits. Done means the function retains the current request behavior while falling back to the raw manifest endpoint when that request fails or is rate-limited; compare the related setup-python and setup-go changes for context.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, typescript
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100