-
Notifications
You must be signed in to change notification settings - Fork 8
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
Use another github.token
on exceeding rate limits
#24
Comments
I find it hard to believe that we are hitting limits on the dedicated deployer's auth. I don't think this is the full picture. Perhaps its org wide, where any app within our org is adding to a sum total "secondary rate limit" In which case, we can create separate apps/auth in our other organizations. This is just a guess, but we don't have 5000+ deploys per hour so I don't see how we could possibly be close to limits, unless its a cumulative total across all our apps?
I think the array approach is more scalable. |
/start |
Tip
|
@Sadaf-A, this task has been idle for a while. Please provide an update. |
app_id and app_private_key action inputs should be arrays so that here a random app was selected every time on deployment in order not to exceed github API rate limits when only 1 deployer app is used (which is the case right now) |
Check this CI run which failed with the
RequestError [HttpError]: You have exceeded a secondary rate limit. Please wait a few minutes before you try again.
error.This error blocks checking PRs because we have to wait some time before running cloudflare deployment again so that preview URL is created (example).
Right now we use https://github.com/apps/ubiquity-os-deployer app's github token for deploying previews of all of our repositories. This approach quickly exceed github API rate limits.
Possible solutions:
github.token
app_id
andapp_private_key
values of available deployer apps. On actual deployment randomly select any.The text was updated successfully, but these errors were encountered: