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

Org folders repository folder never runs scans on repository

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • branch-api-plugin
    • None
    • Jenkins 2.101, Folders Plugin 6.3, GitHub Branch Source Plugin 2.3.2

      Recently updated Jenkins and all available plugins, and the Repository folder within our Organization folder stopped scanning completely. 

       

      I went so far as to delete our entire organization structure and re-create it. The organization does scan correctly on changes. The only time the repository level folder scans automatically is upon its initial creation from the creation of the organization. 

       

      Also makes little sense that the repository folder has a non-configurable interval of 1 day, while the organization folder was setup with an interval of 5 minutes. This is how the repo's trigger is defined in its config.xml:

      <spec>H H * * *</spec>
      <interval>86400000</interval>
      

      I manually changed that to match the Org folders config trigger, e.g. 

      <spec>H/12 * * * *</spec>
      <interval>300000</interval>

      and then gave Jenkins a restart. After ~5 minutes, sure enough, it's now scanning correctly. 

       

      So why on earth is the interval timer being set to such a long duration, and so dramatically different than the org's interval timer? 

          [JENKINS-48960] Org folders repository folder never runs scans on repository

          James Hardwick created issue -
          Stephen Connolly made changes -
          Component/s New: branch-api-plugin [ 18621 ]
          Component/s Original: cloudbees-folder-plugin [ 18137 ]

          Thomas K added a comment -

          I believe I'm experiencing the same problem. Just to clarify, you have to add this custom interval to each and every repository in the organization folder, correct? Not really a particularly good way to handle things.

          Does anybody know which plugin/plugin version is responsible for this? I'd like to try to downgrade it until this issue is fixed.

          Thomas K added a comment - I believe I'm experiencing the same problem. Just to clarify, you have to add this custom interval to each and every repository in the organization folder, correct? Not really a particularly good way to handle things. Does anybody know which plugin/plugin version is responsible for this? I'd like to try to downgrade it until this issue is fixed.

          thomaskasene we only have one repository at the moment that contains Jenkinsfile's but yes, I'd assume so. Thankfully at least it's only a one time change unless of course you delete the organization and recreate it completely. 

          At the time that it happened I tried downgrading several of the plugins that seemed related, but continued to see the same behavior. I couldn't narrow it down, and so started digging for a workaround instead. 

           

          James Hardwick added a comment - thomaskasene we only have one repository at the moment that contains Jenkinsfile's but yes, I'd assume so. Thankfully at least it's only a one time change unless of course you delete the organization and recreate it completely.  At the time that it happened I tried downgrading several of the plugins that seemed related, but continued to see the same behavior. I couldn't narrow it down, and so started digging for a workaround instead.   

          Thomas K added a comment -

          Hmm yes - I'm fortunate enough to struggle with dozens of repositories per organization folder, so manually updating config.xml for each one isn't feasible; it defeats any reason I had for using the plugin in the first place, as webhooks isn't an option for us just yet.

          Thomas K added a comment - Hmm yes - I'm fortunate enough to struggle with dozens of repositories per organization folder, so manually updating config.xml for each one isn't feasible; it defeats any reason I had for using the plugin in the first place, as webhooks isn't an option for us just yet.

          Thomas K added a comment -

          Hmm - I tried your workaround, and changed it to:

          <com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger plugin="cloudbees-folder@6.3">
              <spec>* * * * *</spec>
              <interval>60000</interval>
          </com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger>

          in an attempt to make it scan every minute or so. It didn't take long for it to revert to this, however:

          <com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger plugin="cloudbees-folder@6.3">
              <spec>H H * * *</spec>
              <interval>86400000</interval>
          </com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger>

          So it doesn't seem like it's a possible workaround for me after all. Did you encounter this problem, hardwickj?

          Thomas K added a comment - Hmm - I tried your workaround, and changed it to: <com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger plugin="cloudbees-folder@6.3"> <spec>* * * * *</spec> <interval>60000</interval> </com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger> in an attempt to make it scan every minute or so. It didn't take long for it to revert to this, however: <com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger plugin="cloudbees-folder@6.3"> <spec>H H * * *</spec> <interval>86400000</interval> </com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger> So it doesn't seem like it's a possible workaround for me after all. Did you encounter this problem, hardwickj ?

          thomaskasene mine is still set. Something is odd between the spec and interval relationship. The first time I tried it, I changed only the interval and it reset like you described. When I copied the spec and interval from the parent org folder, it then remained and worked as expected. 

          James Hardwick added a comment - thomaskasene mine is still set. Something is odd between the spec and interval relationship. The first time I tried it, I changed only the interval and it reset like you described. When I copied the spec and interval from the parent org folder, it then remained and worked as expected. 

          Does it scan after a day or does it just not scan at all?

          And what happens if you set the org folder scan to faster than a day?

          I am wondering if https://github.com/jenkinsci/cloudbees-folder-plugin/blob/master/src/main/java/com/cloudbees/hudson/plugins/folder/computed/PeriodicFolderTrigger.java#L201 is the root cause.

          Basically, every time a PeriodicFolderTrigger is instantiated, it gets its lastTriggered reset to 0.

          If the Org Folder scan is updating the PeriodicFolderTrigger instance, that would set lastTriggered back to 0... which will mean that it will be initialized to a random time in the next day... chances are that will not be before Org Folder wipes the periodic folder trigger again... resetting the whole process.

           

          To confirm my analysis you would need to set the Org Folder to a longer period like 2 days or weekly... then you should see the daily scans and then once the org folder scan kicks in, the 24h interval of any one repo's daily scan should end up being delayed by some random amount before resuming the 24h interval again.

           

          If you can confirm the above, we should be able to find a way to preserve the lastTriggered between runs and prevent the issue.

           

          P.S. Can you file a separate JIRA to allow configuring the periodic trigger of the multibranch projects in an org folder, Thanks in advance

          Stephen Connolly added a comment - Does it scan after a day or does it just not scan at all? And what happens if you set the org folder scan to faster than a day? I am wondering if https://github.com/jenkinsci/cloudbees-folder-plugin/blob/master/src/main/java/com/cloudbees/hudson/plugins/folder/computed/PeriodicFolderTrigger.java#L201  is the root cause. Basically, every time a PeriodicFolderTrigger is instantiated, it gets its lastTriggered reset to 0. If the Org Folder scan is updating the PeriodicFolderTrigger instance, that would set lastTriggered back to 0... which will mean that it will be initialized to a random time in the next day... chances are that will not be before Org Folder wipes the periodic folder trigger again... resetting the whole process.   To confirm my analysis you would need to set the Org Folder to a longer period like 2 days or weekly... then you should see the daily scans and then once the org folder scan kicks in, the 24h interval of any one repo's daily scan should end up being delayed by some random amount before resuming the 24h interval again.   If you can confirm the above, we should be able to find a way to preserve the lastTriggered between runs and prevent the issue.   P.S. Can you file a separate JIRA to allow configuring the periodic trigger of the multibranch projects in an org folder, Thanks in advance

          https://github.com/jenkinsci/branch-api-plugin/blob/dcc0d23a0870058c6138362d3aa017c0d56effc2/src/main/java/jenkins/branch/OrganizationFolder.java#L1429 is where the 1d default is coming from BTW. I am not seeing any code path that would revert it after the repository project has been created

          Stephen Connolly added a comment - https://github.com/jenkinsci/branch-api-plugin/blob/dcc0d23a0870058c6138362d3aa017c0d56effc2/src/main/java/jenkins/branch/OrganizationFolder.java#L1429  is where the 1d default is coming from BTW. I am not seeing any code path that would revert it after the repository project has been created

          Having the same issue (with bitbucket branch source instead of github).
          I also tried to set it through one of the jobs with

          pipelineTriggers([[$class: 'PeriodicFolderTrigger', interval: '5m']]),

          But didn't work either.

          Patrick Ruckstuhl added a comment - Having the same issue (with bitbucket branch source instead of github). I also tried to set it through one of the jobs with pipelineTriggers([ [$class: 'PeriodicFolderTrigger', interval: '5m'] ]), But didn't work either.

            Unassigned Unassigned
            hardwickj James Hardwick
            Votes:
            32 Vote for this issue
            Watchers:
            42 Start watching this issue

              Created:
              Updated: