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

Repository scan constantly checking tags, hitting rate limits

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Critical
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins: version 2.124
      github-branch-source-plugin: version 2.3.4
      Operating System: Debian GNU/Linux 9 in Docker container via kubernetes-plugin
    • Similar Issues:

      Description

      I have an organization set with "Discover Tags" enabled under "Github Organization". One of the repos under this project has a significant number of tags. The "Repository Events" for this repo seems to show a nearly constant loop checking the full list of tags.

      This is eating up our Github API requests and hitting the plugin's throttling:

      Checking tag v0.1.1
      GitHub API Usage: Current quota has 1664 remaining (2 over budget). Next quota of 5000 in 22 min. Sleeping for 26 sec.

      The "checking tag XXXXX" entries keep cycling through all of the tags. We also have Branches and PR's enabled for this organization. Those does not seem to be doing the same constant polling in the repo event logs unless there is a change pushed.

      Is this expected behavior? Is there anyway to avoid doing so many checks for existing tags?

        Attachments

          Activity

          Hide
          danielfm Daniel Martins added a comment -

          We are being hit pretty hard by this as well.

          We have a couple of high-activity repositories with a few thousand tags each, and I can also see the constant tag scanning behavior in their respective "Repository Events" screen; branches are constanly being created/updated, so it's common for builds to be delayed for several minutes due to the plugin's rate limit protections.

          In the attached screenshot I show one of these events in which a push to some branch triggered the tag scanning behavior.

          I also found what it seems to be the relevant portion of the source code that seems to confirm the mentioned behavior (a push to a branch triggers the tag scanning).

          This behavior doesn't make much sense to me, especially for large repositories with a huge number of tags.

          Is there any way we can disable this behavior?

          Show
          danielfm Daniel Martins added a comment - We are being hit pretty hard by this as well. We have a couple of high-activity repositories with a few thousand tags each, and I can also see the constant tag scanning behavior in their respective "Repository Events" screen; branches are constanly being created/updated, so it's common for builds to be delayed for several minutes due to the plugin's rate limit protections. In the attached screenshot I show one of these events in which a push to some branch triggered the tag scanning behavior. I also found what it seems to be the relevant portion of the source code that seems to confirm the mentioned behavior (a push to a branch triggers the tag scanning). This behavior doesn't make much sense to me, especially for large repositories with a huge number of tags. Is there any way we can disable this behavior?
          Hide
          frank_bartz fbartz added a comment -

          we are also affected by this, did anybody already found out any way to disable that bahavior?

          Show
          frank_bartz fbartz added a comment - we are also affected by this, did anybody already found out any way to disable that bahavior?
          Hide
          atcarmo André Carmo added a comment - - edited

          We're also being affected by this situation.

           

          Jenkins 2.263.4

          github branch source 2.9.7

          Show
          atcarmo André Carmo added a comment - - edited We're also being affected by this situation.   Jenkins 2.263.4 github branch source 2.9.7

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            davekonopka Dave Konopka
            Votes:
            4 Vote for this issue
            Watchers:
            9 Start watching this issue

              Dates

              Created:
              Updated: