-
Bug
-
Resolution: Unresolved
-
Minor
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' ) } }
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.