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

UX Issue with Polling in Multibranch Pipeline

      There is general confusing about how polling behaves in multibranch pipeline. Polling will continue to trigger the same revision over and over again because mutlibranch is pinned to the revision found in computation.

      For now we should disable the trigger in properties step of a multibranch pipeline.

      The recommendation for users not using webhooks would be to configure the "Periodically if not otherwise run" but this will add more api calls.

          [JENKINS-41074] UX Issue with Polling in Multibranch Pipeline

          Jesse Glick added a comment -

          As a step towards JENKINS-32018, we could rather permit SCMTrigger but amend WorkflowJob.poll to ignore polling on any SCM which came from a branch project (i.e., scm argument to checkout rather than something else).

          Jesse Glick added a comment - As a step towards JENKINS-32018 , we could rather permit SCMTrigger but amend WorkflowJob.poll to ignore polling on any SCM which came from a branch project (i.e., scm argument to checkout rather than something else).

          Patrick Wolf added a comment -

          Disabling polling from properties means that it cannot be used in job configuration if any other properties are set. https://issues.jenkins-ci.org/browse/JENKINS-41146

          Patrick Wolf added a comment - Disabling polling from properties means that it cannot be used in job configuration if any other properties are set. https://issues.jenkins-ci.org/browse/JENKINS-41146

          Jesse Glick added a comment -

          Note that TimerTrigger (cron symbol) is occasionally desirable and unproblematic. For example, someone wants their master branch built every night, even if there are no recorded commits.

          Jesse Glick added a comment - Note that TimerTrigger ( cron symbol) is occasionally desirable and unproblematic. For example, someone wants their master branch built every night, even if there are no recorded commits.

          Jesse Glick added a comment -

          amend WorkflowJob.poll to ignore polling on any SCM which came from a branch project

          I think this is really the correct behavior, rather than disabling polling altogether. The poll method gets a log handle so it can print a message about why it is ignoring polling on this SCM.

          What I am not sure about is how to implement this. SCMVar just gets to pass back an SCM, of some plugin-provided type, and SCMStep does not have any particular way of knowing where it came from. You can easily find the SCMRevisionAction indicating that a branch source was active on this build, but the old API SCMListener.onCheckout just gets a SCMRevisionState, which is what is stored for future use from WorkflowJob.poll, and there is no API for correlating an SCMRevisionState with an SCMRevision: these capture essentially similar information but they are not interconvertible. Perhaps scm-api could be amended so that SCMRevision could check whether it was the same as a given SCMRevisionState. Unfortunately even with such an API, there is no way the git plugin will soon support this, until JENKINS-19022 is implemented so that it actually uses SCMRevisionState as the API mandates.

          Jesse Glick added a comment - amend WorkflowJob.poll to ignore polling on any SCM which came from a branch project I think this is really the correct behavior, rather than disabling polling altogether. The poll method gets a log handle so it can print a message about why it is ignoring polling on this SCM. What I am not sure about is how to implement this. SCMVar just gets to pass back an SCM , of some plugin-provided type, and SCMStep does not have any particular way of knowing where it came from. You can easily find the SCMRevisionAction indicating that a branch source was active on this build, but the old API SCMListener.onCheckout just gets a SCMRevisionState , which is what is stored for future use from WorkflowJob.poll , and there is no API for correlating an SCMRevisionState with an SCMRevision : these capture essentially similar information but they are not interconvertible. Perhaps scm-api could be amended so that SCMRevision could check whether it was the same as a given SCMRevisionState . Unfortunately even with such an API, there is no way the git plugin will soon support this, until JENKINS-19022 is implemented so that it actually uses SCMRevisionState as the API mandates.

          Jesse Glick added a comment -

          If you know about it, the correct behavior could be implemented using (untested!)

          properties([pipelineTriggers([pollSCM('@daily')])])
          node {
            dir('main') {
              // do not use SCMTrigger here, use branch indexing
              checkout scm: scm, poll: false
            }
            dir('other') {
              checkout([$class: 'GitSCM', userRemoteConfigs: [[url: 'http://wherever/']]])
            }
          }
          

          Jesse Glick added a comment - If you know about it, the correct behavior could be implemented using (untested!) properties([pipelineTriggers([pollSCM( '@daily' )])]) node { dir( 'main' ) { // do not use SCMTrigger here, use branch indexing checkout scm: scm, poll: false } dir( 'other' ) { checkout([$class: 'GitSCM' , userRemoteConfigs: [[url: 'http: //wherever/' ]]]) } }

          Justin Vallon added a comment -

          jglick: I am trying to get github/repoA/Jenkinsfile to use github/repoB.  The sample code that you provided works (polling, on a schedule).  Is it possible to get it to work on-push for rebuild of repoA when repoB is pushed?

          When I use pollSCM("# on push"), nothing happens (either on push or at any later point).  I am guessing that the $Jenkins/github-webhook is not triggering the immediate pollSCM?

          If I use githubPush() trigger, it double-triggers the main-repo (sometimes the builds are coalesced, sometimes not if concurrent builds are allowed); but I think this ticket implies that the githubPush() trigger should not be used in org/repo/branch jobs.

          Alternately, I suppose I could add upstream-downstream relationships, but I have been trying to keep the triggers based on SCM vs jobs.

          Note though that my Jenkins is at 2.60.1, and GitHub Branch Source 2.0.7 (a few months old), so maybe I should try upgrading, but it is probably my expectation that is wrong (user error, not a bug).

          Justin Vallon added a comment - jglick : I am trying to get github/repoA/Jenkinsfile to use github/repoB.  The sample code that you provided works (polling, on a schedule).  Is it possible to get it to work on-push for rebuild of repoA when repoB is pushed? When I use pollSCM("# on push"), nothing happens (either on push or at any later point).  I am guessing that the $Jenkins/github-webhook is not triggering the immediate pollSCM? If I use githubPush() trigger, it double-triggers the main-repo (sometimes the builds are coalesced, sometimes not if concurrent builds are allowed); but I think this ticket implies that the githubPush() trigger should not be used in org/repo/branch jobs. Alternately, I suppose I could add upstream-downstream relationships, but I have been trying to keep the triggers based on SCM vs jobs. Note though that my Jenkins is at 2.60.1, and GitHub Branch Source 2.0.7 (a few months old), so maybe I should try upgrading, but it is probably my expectation that is wrong (user error, not a bug).

          Justin Vallon added a comment -

          So, got it working.  On (enterprise) github, installed the "Jenkins (git plugin)" integration service which started calling the git-hook.

          Justin Vallon added a comment - So, got it working.  On (enterprise) github, installed the "Jenkins (git plugin)" integration service which started calling the git-hook.

          Hezi Zisman added a comment -

          What is the recommenations for those who use webhooks and branch indexing?

          We expirencing allot of duplicated builds...

          Disabling branch indexing will cause new branches not to get indexed and built

          Disabling webhooks will break a build per push bond we need...

          Hezi Zisman added a comment - What is the recommenations for those who use webhooks and branch indexing? We expirencing allot of duplicated builds... Disabling branch indexing will cause new branches not to get indexed and built Disabling webhooks will break a build per push bond we need...

            Unassigned Unassigned
            hrmpw Patrick Wolf
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: