jenkinsci
[JENKINS-44426] GitHub still triggering on SCM changes after polling option set to false
I set up a test Pipeline job and found a bug with the GitHub plugin's webhooks (this issue may also exist for polling but I did not test that case).
I used two repos during testing:
mksmith_test: Repo with just README
mksmith_test2: Repo with Jenkinsfile and README
Here is the simple Jenkinsfile that I started with in mksmith_test2:
stage("Prep") { node("general-centos7") { checkout(changelog: false, poll: false, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "git@git.xxx.com:mksmith/mksmith_test2.git"]]]) checkout(changelog: true, poll: true, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "git@git.xxx.com:mksmith/mksmith_test.git"]]]) } }
With this setup, I ran a build manually (in order to initialize the polling baselines) and then made updates to each repo. Hooks behaved as expected
- Update README in mksmith_test (triggered a build)
- Update README in mksmith_test2 (did not trigger a build because poll: false)
This behavior makes sense. See the image "poll_false_before" that I have attached to this ticket. This shows that it is only looking at mksmith_test.
I then updated the Jenkinsfile to have a checkout(scm) instead of a full checkout step defined with poll: false.
stage("Prep") { node("general-centos7") { checkout(scm) /*checkout(changelog: false, poll: false, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "git@git.xxx.com:mksmith/mksmith_test2.git"]]])*/ checkout(changelog: true, poll: true, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "git@git.xxx.com:mksmith/mksmith_test.git"]]]) } }
I then did the following
- Update README in mksmith_test (triggered a build)
- Update README in mksmith_test2 (triggered a build. I suppose this is because checkout(scm) sets polling to true by default)
This behavior seems to make sense. See the image "checkout_scm" that I have attached to this ticket. This shows that Jenkins is looking at both mksmith_test and mksmith_test2 for changes.
Triggering was still behaving as expected, until I made the next change. I reverted the Jenkinsfile to it's original state:
stage("Prep") { node("general-centos7") { checkout(changelog: false, poll: false, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "git@git.xxx.com:mksmith/mksmith_test2.git"]]]) checkout(changelog: true, poll: true, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "git@git.xxx.com:mksmith/mksmith_test.git"]]]) } }
I then did the following:
- Update README in mksmith_test2 (triggered a build. This makes sense because Jenkins hasn't been able to look at the updated checkout call in mksmith_test2 yet)
- Update README in mksmith_test2 (triggered a build. This doesn't make sense. Jenkins should not be triggering off of mksmith_test2 anymore)
This behavior does NOT make sense. See the image "poll_false_after" that I have attached to this ticket. This was the polling log after the second commit to mksmith_test2. This shows that Jenkins is STILL looking at both mksmith_test and mksmith_test2 for changes. Multiple commits to mksmith_test2 after produced the same result. The pipeline still triggered off of changes to that repo.
I believe the expected behavior should be that the pipeline only triggers off of changes to mksmith_test after the Jenkinsfile is updated to set polling to false on the mksmith_test2 checkout. Why is this reference to mksmith_test2 being preserved in polling?
To further verify the bug, I created another pipeline job by simply copying the final state of the pipeline job I used in the tests described above. In this newly created pipeline job (with identical configuration to the one used in the tests), commits to mksmith_test2 did NOT trigger builds.
It seems like the temporary switch to "checkout(scm)" cause Jenkins to trigger off of changes to mksmith_test2 and it never switched back, even after the Jenkinsfile was updated.
Originally reported by 
mksmith, imported from: GitHub still triggering on SCM changes after polling option set to false
- assignee:
lanwen
- status: Open
- priority: Major
- component(s): github-plugin
- label(s): github-plugin
- resolution: Unresolved
- votes: 3
- watchers: 8
- imported: 2025-12-08
Raw content of original issue
I set up a test Pipeline job and found a bug with the GitHub plugin's webhooks (this issue may also exist for polling but I did not test that case).
I used two repos during testing:
mksmith_test: Repo with just README
mksmith_test2: Repo with Jenkinsfile and README
Here is the simple Jenkinsfile that I started with in mksmith_test2:
stage("Prep") { node("general-centos7") { checkout(changelog: false, poll: false, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "[email protected]:mksmith/mksmith_test2.git"]]]) checkout(changelog: true, poll: true, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "[email protected]:mksmith/mksmith_test.git"]]]) } }With this setup, I ran a build manually (in order to initialize the polling baselines) and then made updates to each repo. Hooks behaved as expected
- Update README in mksmith_test (triggered a build)
- Update README in mksmith_test2 (did not trigger a build because poll: false)
This behavior makes sense. See the image "poll_false_before" that I have attached to this ticket. This shows that it is only looking at mksmith_test.
I then updated the Jenkinsfile to have a checkout(scm) instead of a full checkout step defined with poll: false.
stage("Prep") { node("general-centos7") { checkout(scm) /*checkout(changelog: false, poll: false, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "[email protected]:mksmith/mksmith_test2.git"]]])*/ checkout(changelog: true, poll: true, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "[email protected]:mksmith/mksmith_test.git"]]]) } }
I then did the following
- Update README in mksmith_test (triggered a build)
- Update README in mksmith_test2 (triggered a build. I suppose this is because checkout(scm) sets polling to true by default)
This behavior seems to make sense. See the image "checkout_scm" that I have attached to this ticket. This shows that Jenkins is looking at both mksmith_test and mksmith_test2 for changes.
Triggering was still behaving as expected, until I made the next change. I reverted the Jenkinsfile to it's original state:
stage("Prep") { node("general-centos7") { checkout(changelog: false, poll: false, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "[email protected]:mksmith/mksmith_test2.git"]]]) checkout(changelog: true, poll: true, scm: [$class: "GitSCM", branches: [[name: "master"]], userRemoteConfigs: [[credentialsId: "ssh_key", url: "[email protected]:mksmith/mksmith_test.git"]]]) } }
I then did the following:
- Update README in mksmith_test2 (triggered a build. This makes sense because Jenkins hasn't been able to look at the updated checkout call in mksmith_test2 yet)
- Update README in mksmith_test2 (triggered a build. This doesn't make sense. Jenkins should not be triggering off of mksmith_test2 anymore)
This behavior does NOT make sense. See the image "poll_false_after" that I have attached to this ticket. This was the polling log after the second commit to mksmith_test2. This shows that Jenkins is STILL looking at both mksmith_test and mksmith_test2 for changes. Multiple commits to mksmith_test2 after produced the same result. The pipeline still triggered off of changes to that repo.
I believe the expected behavior should be that the pipeline only triggers off of changes to mksmith_test after the Jenkinsfile is updated to set polling to false on the mksmith_test2 checkout. Why is this reference to mksmith_test2 being preserved in polling?
To further verify the bug, I created another pipeline job by simply copying the final state of the pipeline job I used in the tests described above. In this newly created pipeline job (with identical configuration to the one used in the tests), commits to mksmith_test2 did NOT trigger builds.
It seems like the temporary switch to "checkout(scm)" cause Jenkins to trigger off of changes to mksmith_test2 and it never switched back, even after the Jenkinsfile was updated.
environment
Jenkins 2.46.2<br/>
GitHub Plugin 1.27.0<br/>
GitHub API Plugin 1.85<br/>
SCM API Plugin 2.1.1<br/>
Git plugin 3.3.0<br/>
Git client plugin 2.4.5
3 attachments
sylvainjoyeux:
- Original comment link
Raw content of original comment:
I have an issue with poll: false that closely resembles this ... but does not need any form of mumbo-jumbo
I'm "manually" (scripted through the API) creating pipelines. These pipelines checkout one common repo with poll: false and "their" repo with poll: true. However, builds are triggered by the poll: false line nonetheless.
I have an issue with poll: false that closely resembles this ... but does not need any form of mumbo-jumbo
I'm "manually" (scripted through the API) creating pipelines. These pipelines checkout one common repo with poll: false and "their" repo with poll: true. However, builds are triggered by the poll: false line nonetheless.
gabo:
- Original comment link
Raw content of original comment:
one year and no response at all?
mksmith do u still have this problem?
I have a very similar issue. I have a working pipepile that uses 2 github repos, both had polling enabled.
I now disabled the polling on the second repo, but is still triggering builds.
one year and no response at all?
mksmith do u still have this problem?
I have a very similar issue. I have a working pipepile that uses 2 github repos, both had polling enabled.
I now disabled the polling on the second repo, but is still triggering builds.
mksmith:
- Original comment link
Raw content of original comment:
gabo I don't know. I'll test this again with a newer version of Jenkins when I get the chance
gabo I don't know. I'll test this again with a newer version of Jenkins when I get the chance
deiwin:
- Original comment link
Raw content of original comment:
It is still an issue. I'm using the following instead of poll: false as a workaround. It works, but it has the downside that all the repositories that use checkout have to be cloned to a workspace every time one of them is pushed to, even though none of them will actually trigger the build.
extensions: [[$class: 'PathRestriction', includedRegions: '__nothing__']]
It is still an issue. I'm using the following instead of poll: false as a workaround. It works, but it has the downside that all the repositories that use checkout have to be cloned to a workspace every time one of them is pushed to, even though none of them will actually trigger the build.
extensions: [[$class: 'PathRestriction', includedRegions: '__nothing__']]