You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having another look at the failed job, this isn't only an org scan, but it also scans all the repos in this org. So, my current assumption is, the rate limit is applied to the repo, the action is running in, not the repo that is queried. So, splitting up the repo scans across the repos would also solve the rate limit, but makes it also unmanageable in large orgs.
How could we separate the org scan and the repo scans without losing the ability to automatically detect all the repos?
Perhaps @benr had this on his mind, when suggesting solution 2:
Perhaps something like pagination would work? Running a workflow for the org + 50 first repos, another workflow for the 2nd 50 repos, ...
But that would be another burden on the user, and might also miss repos.
Scans of orgs of any reasonable size will fail due to the Github API Rate Limit. There should be a parameter to reduce the scan rate.
A consequence of slowing the scan rate will be excessive number of minutes spent in the action, which might mean the only solutions are:
The text was updated successfully, but these errors were encountered: