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

UX Issue with Polling in Multibranch Pipeline

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            jglick 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).

            Show
            jglick 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).
            Hide
            hrmpw 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

            Show
            hrmpw 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
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            jglick 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/']]])
              }
            }
            
            Show
            jglick 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/' ]]]) } }
            Hide
            vallon Justin Vallon added a comment -

            Jesse Glick: 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).

            Show
            vallon Justin Vallon added a comment - Jesse Glick : 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).
            Hide
            vallon 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.

            Show
            vallon 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.
            Hide
            h3zi 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...

            Show
            h3zi 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...

              People

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

                Dates

                • Created:
                  Updated: