-
New Feature
-
Resolution: Fixed
-
Minor
-
None
-
-
github-branch-source-2.9.0
We are using a private instance of GitHub Enterprise, for which the rate limit is disabled.
Our operations team was complaining that we were flooding their monitoring of the enterprise server with rate_limit requests, which is completely unnecessary, since we have rate_limit disabled, so nothing will ever be throttled.
The idea would be to add an extra ApiRateLimitChecker type, called NoThrottle, that simply doesn't check for rate limits, avoiding thus the unnecessary calls.
- relates to
-
JENKINS-68321 SCMEvent threads waiting on rate limit when rate limit isn't close to being hit
-
- Open
-
[JENKINS-63078] Allow ignoring GitHub rate limits
Marc Salles Navarro
created issue -
Marc Salles Navarro
made changes -
| Description |
Original:
We are using GitHub enterprise, for which rate limit is disabled. Our operations team was complaining that we were flooding their monitoring of the enterprise server with rate_limit requests, which is completely unnecessary, since we have rate_limit disabled, so nothing will ever be throttled. The idea would be to add an extra ApiRateLimitChecker type, called NoThrottle, that simply doesn't check for rate limits, avoiding thus the unnecessary calls. |
New:
We are using a private instance of GitHub Enterprise, for which the rate limit is disabled. Our operations team was complaining that we were flooding their monitoring of the enterprise server with rate_limit requests, which is completely unnecessary, since we have rate_limit disabled, so nothing will ever be throttled. The idea would be to add an extra ApiRateLimitChecker type, called NoThrottle, that simply doesn't check for rate limits, avoiding thus the unnecessary calls. |
We were getting 500s from the GitHub API, and apparently our enterprise github was processing over 3 million requests per day, which according to Github support was way too much.
I forked a couple plugins to try to reduce the amount of requests we were sending, the other one being branch-api-plugin, and it seemed to address the issue.
While I understand that such an option has a bit of risk, it's still a non-default admin option - maybe some explicit warning could be added to its selector description?
Marc Salles Navarro
added a comment - - edited We were getting 500s from the GitHub API, and apparently our enterprise github was processing over 3 million requests per day, which according to Github support was way too much.
I forked a couple plugins to try to reduce the amount of requests we were sending, the other one being branch-api-plugin, and it seemed to address the issue.
While I understand that such an option has a bit of risk, it's still a non-default admin option - maybe some explicit warning could be added to its selector description? | Resolution | New: Fixed [ 1 ] | |
| Status | Original: Open [ 1 ] | New: Fixed but Unreleased [ 10203 ] |
| Released As | New: github-branch-source-2.9.0 | |
| Status | Original: Fixed but Unreleased [ 10203 ] | New: Closed [ 6 ] |
| Link | New: This issue relates to JENKINS-68321 [ JENKINS-68321 ] |
Hm, could you give some specifics about what they mean by "flooding"?
I would be hesitant to create a "No Throttle" checker - if someone accidentally set that when connecting to github.com the consequences could be very unpleasant.
There is other work being done to move the rate limit checking down into the the github-api library which can do smarter things around checking.