-
Notifications
You must be signed in to change notification settings - Fork 552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance setup-python Action in GitHub Enterprise Server with Raw API Fallback Mechanism #756
Comments
Hello @Shegox. Thank you for your report. We'll take a look on it. |
I had some more time today and created #766 as an implementation of this idea, would be happy about feedback and maybe getting this merged :) |
Hello @Shegox 👋, |
@priya-kinthali just checked it again and it works with the
I checked as well that the current PR (#766) doesn't overwrite any changes to the transpiled dist. So from my side it is good to be merged. Looking forward to seeing it merged! |
@priya-kinthali did you have time to check on this issue and the PR (#766)? |
Hello @Shegox 👋, |
Description:
In the context of GitHub Enterprise Server (GHES), it is typical for runners to share the same IP address due to Network Address Translation (NAT). This configuration results in the quick exhaustion of the unauthenticated rate limit (60 requests per hour per IP address) when accessing the
versions-manifest.json
file, leading to failures in thesetup-python
action. The current workaround is to incorporate a "github.com" token into thesetup-python
action. Although this solution is functional, it necessitates the creation of an additional github.com token (and technical user) for each repository/team, which is not optimal. Moreover, Pull Requests from forks are not supported due to their lack of access to the secret.A potential improvement could be leveraging the
raw
API to retrieve the version-manifest, as it does not impose a rate limit and hence facilitates unrestricted consumption without the need for a token.Justification:
Our GitHub Enterprise Server has frequently encountered rate limit issues, and the manual token addition method does not scale well. Utilizing the raw API as a fallback could provide an automatic workaround for this issue. If this approach fails, users can still resort to adding a token.
Are you willing to submit a PR?
I have created a fork to verify that the raw API isn't affected by the rate limit and can be used as a fallback solution. (https://github.com/actions/setup-python/compare/main...Shegox:setup-python:raw-access?expand=1)
The log extract from the workaround is as follows:
I am prepared to submit a PR incorporating the proposed changes.
Before proposing this PR I wanted to check if that would be accepted or if there are other ideas to overcome this?
Related Issues
The text was updated successfully, but these errors were encountered: