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

GitHub still triggering on SCM changes after polling option set to false

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: github-plugin
    • Labels:
    • Environment:
      Jenkins 2.46.2
      GitHub Plugin 1.27.0
      GitHub API Plugin 1.85
      SCM API Plugin 2.1.1
      Git plugin 3.3.0
      Git client plugin 2.4.5
    • Similar Issues:

      Description

      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. 

       

        Attachments

          Issue Links

            Activity

            Hide
            deiwin Deiwin Sarjas added a 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__']]
            Show
            deiwin Deiwin Sarjas added a 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__' ]]
            Hide
            mksmith Matthew Smith added a comment -

            Gabriel Diaz I don't know. I'll test this again with a newer version of Jenkins when I get the chance

            Show
            mksmith Matthew Smith added a comment - Gabriel Diaz I don't know. I'll test this again with a newer version of Jenkins when I get the chance
            Hide
            gabo Gabriel Diaz added a comment -

            one year and no response at all?

            Matthew Smith 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.

            Show
            gabo Gabriel Diaz added a comment - one year and no response at all? Matthew Smith 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.
            Hide
            sylvainjoyeux Sylvain Joyeux added a 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.

            Show
            sylvainjoyeux Sylvain Joyeux added a 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.

              People

              Assignee:
              lanwen Kirill Merkushev
              Reporter:
              mksmith Matthew Smith
              Votes:
              3 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated: