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.