Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-63078

Allow ignoring GitHub rate limits

    XMLWordPrintable

    Details

    • Similar Issues:
    • Released As:
      github-branch-source-2.9.0

      Description

      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.

        Attachments

          Activity

          sirstrahd Marc Salles Navarro created issue -
          sirstrahd Marc Salles Navarro made changes -
          Field Original Value New Value
          Description 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.
          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.
          Hide
          bitwiseman Liam Newman added a comment -

          Our operations team was complaining that we were flooding their monitoring of the enterprise server with rate_limit requests

          .

          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.

          Show
          bitwiseman Liam Newman added a comment - Our operations team was complaining that we were flooding their monitoring of the enterprise server with rate_limit requests . 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.
          Hide
          sirstrahd 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?

          Show
          sirstrahd 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?
          bitwiseman Liam Newman made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Fixed but Unreleased [ 10203 ]
          bitwiseman Liam Newman made changes -
          Released As github-branch-source-2.9.0
          Status Fixed but Unreleased [ 10203 ] Closed [ 6 ]

            People

            Assignee:
            sirstrahd Marc Salles Navarro
            Reporter:
            sirstrahd Marc Salles Navarro
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: