Skip to content
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

Open
rndquu opened this issue Oct 16, 2024 · 7 comments
Open

Use another github.token on exceeding rate limits #24

rndquu opened this issue Oct 16, 2024 · 7 comments

Comments

@rndquu
Copy link
Member

rndquu commented Oct 16, 2024

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:

  • here check that if app's github token is about to be rate limited then fallback to github.token
  • here provide an array of app_id and app_private_key values of available deployer apps. On actual deployment randomly select any.
@0x4007
Copy link
Member

0x4007 commented Oct 16, 2024

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?

  • here provide an array of app_id and app_private_key values of available deployer apps. On actual deployment randomly select any.

I think the array approach is more scalable.

@rndquu
Copy link
Member Author

rndquu commented Dec 10, 2024

I don't see how we could possibly be close to limits, unless its a cumulative total across all our apps?

There're many ways to reach secondary limits, exceeded CPU time, too many concurrent requests, etc... Overall there're more possible solutions here.

@Sadaf-A
Copy link
Contributor

Sadaf-A commented Dec 20, 2024

/start

Copy link

ubiquity-os bot commented Dec 20, 2024

Warning! This task was created over 65 days ago. Please confirm that this issue specification is accurate before starting.
Deadline Sat, Dec 21, 2:21 AM UTC
Beneficiary 0x0BEd00438D57d07E3667b85Fa8EB86Af147C7025

Tip

  • Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
  • Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
  • Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

@Sadaf-A
Copy link
Contributor

Sadaf-A commented Dec 20, 2024

@rndquu
here provide an array of app_id and app_private_key values of available deployer apps. On actual deployment randomly select any.

could you please shed some more light on this I understood everything else.

Copy link

ubiquity-os bot commented Dec 27, 2024

@Sadaf-A, this task has been idle for a while. Please provide an update.

@rndquu
Copy link
Member Author

rndquu commented Dec 28, 2024

@rndquu here provide an array of app_id and app_private_key values of available deployer apps. On actual deployment randomly select any.

could you please shed some more light on this I understood everything else.

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants