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

Jenkins polling doesn't detect commits in Github

      I am currently using the "Poll SCM" option in Jenkins with the poll frequency set to 1 minute for now. My goal is to trigger the build job when the polling detects a commit in Github. However, despite committing to "Feature" branch multiple times, the polling doesn't detect the commit. It continually displays message similar to this:

      Started on May 18, 2018 4:51:00 PM Using strategy: Default [poll] Last Built Revision: Revision ecf20b8hhh2f3d63b5809mle268024500364f2fb (refs/remotes/origin/feature/template-api) 
      > /usr/bin/git --version # timeout=10 using GIT_ASKPASS to set credentials 
      Setting http proxy: surf.proxy.company:80 
      > /usr/bin/git ls-remote -h https://github.developer.company.com/my- project.git # timeout=10 
      Found 3 remote heads on https://github.developer.company.com/my-project.git 
      Done. 
      Took 3.7 sec 
      No changes
      

      My pipeline script is as below:

      node {
          stage('Preparation') {
              git ( poll: true, branch: 'feature/template-api', credentialsId: '8u56qwcf-e74e-44z3-9437-c81b19cd3a29', url: 'https://github.developer.company.com/my-project.git' )
          }
      }
      

          [JENKINS-51419] Jenkins polling doesn't detect commits in Github

          Mark Waite added a comment - - edited

          The poll: true in the git Pipeline step seems to be described in the workflow-scm-step README. I assume you must be using a Pipeline job (rather than a multi-branch Pipeline job) and are defining the polling frequency in the job definition rather than defining it in inside the Pipeline itself.

          Others have observed that the git Pipeline step is a shorthand form of the checkout step. Rather than use the shorthand git form, you might try the checkout step.

          Examples which use polling with multi-branch Pipeline scripts are available in the following samples that I have gathered:

          Periodic polling inside a Pipeline job is almost always a bad practice. It creates unnecessary load on the git server by asking questions of the git server. The user will have a much better experience if the git server informs the Jenkins server when a change happens rather than having the Jenkins server regularly ask if there are changes. Refer to the "polling must die" blog post from Kohsuke Kawaguchi for more details.

          Mark Waite added a comment - - edited The poll: true in the git Pipeline step seems to be described in the workflow-scm-step README . I assume you must be using a Pipeline job (rather than a multi-branch Pipeline job) and are defining the polling frequency in the job definition rather than defining it in inside the Pipeline itself. Others have observed that the git Pipeline step is a shorthand form of the checkout step. Rather than use the shorthand git form, you might try the checkout step. Examples which use polling with multi-branch Pipeline scripts are available in the following samples that I have gathered: JENKINS-43468 check job JENKINS-43687 check job JENKINS-43754 check job JENKINS-50556 check job JENKINS-50886 check job Periodic polling inside a Pipeline job is almost always a bad practice. It creates unnecessary load on the git server by asking questions of the git server. The user will have a much better experience if the git server informs the Jenkins server when a change happens rather than having the Jenkins server regularly ask if there are changes. Refer to the " polling must die " blog post from Kohsuke Kawaguchi for more details.

            Unassigned Unassigned
            johannko johann ko
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: