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

Global Pipeline Libraries triggers the 'poll SCM' of jobs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Reopened (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      linux rhel7.2
      jenkins 2.19.2
      up to date 'workflow' set of plugins (on stable update center)
    • Similar Issues:

      Description

      I have this situation where :

      • I have some jobs that gets sources from a SCM, and performs a 'poll SCM' hourly
      • I have a 'global pipeline lib' defined, on another SCM (doesn't matter really, what atters is it's not in the same source tree s the jobs)

      My issue is that any commit to the 'global pipeline lib' SCM will be detected by all the jobs that have a 'poll SCM' configured.

      I wish I can exclude the global lib from polling.

      (and yes, I know, polling is evil, whenever I can I have triggers configured on modern scm to push jobs, but sometimes it's just not possible, believe me you don't want to know all the why's)

        Attachments

          Issue Links

            Activity

            squalou squalou jenkins created issue -
            squalou squalou jenkins made changes -
            Field Original Value New Value
            Priority Minor [ 4 ] Major [ 3 ]
            Hide
            squalou squalou jenkins added a comment -

            I allow myself to increase criticality. Why ? because in my infrastructure I have dozens of jenkins master with plenty of jobs in each.

            Our target is to share a common lib, and this feature is really welcome.

            Matter is : each commit to the lib leads to hundreds of jobs triggered. So for now we stopped the deployment of this feature. There is no easy workaround in our case. (again : if I could get rid of poll-scm I would, but I can't)

            Show
            squalou squalou jenkins added a comment - I allow myself to increase criticality. Why ? because in my infrastructure I have dozens of jenkins master with plenty of jobs in each. Our target is to share a common lib, and this feature is really welcome. Matter is : each commit to the lib leads to hundreds of jobs triggered. So for now we stopped the deployment of this feature. There is no easy workaround in our case. (again : if I could get rid of poll-scm I would, but I can't)
            Hide
            jglick Jesse Glick added a comment -

            Probably same as JENKINS-38679; needs investigation and a minimal test case.

            Show
            jglick Jesse Glick added a comment - Probably same as JENKINS-38679 ; needs investigation and a minimal test case.
            jglick Jesse Glick made changes -
            Link This issue duplicates JENKINS-38679 [ JENKINS-38679 ]
            Hide
            squalou squalou jenkins added a comment -

            I can explain a very simple testcase if you want.

            setup

            declare a workflow lib, call it 'test-lib', in jenkins global settings, pointing, say, to GIT some-test-ib-repo

            create a workflow job

            Point the pipeline to a Jenkinsfile hosted another GIT repo (some-repo/some-project.git)

            stage ('dummy'){
            println 'I have run'
            }
            

            Tick 'POLL SCM', H/5 * * * * should do

            test

            submit anything on 'some-test-ib-repo', which is NOT the repo of the scm declared in the pipeline

            wait 5 minutes

            the job runs.

            Show
            squalou squalou jenkins added a comment - I can explain a very simple testcase if you want. setup declare a workflow lib, call it 'test-lib', in jenkins global settings, pointing, say, to GIT some-test-ib-repo create a workflow job Point the pipeline to a Jenkinsfile hosted another GIT repo (some-repo/some-project.git) stage ( 'dummy' ){ println 'I have run' } Tick 'POLL SCM', H/5 * * * * should do test submit anything on 'some-test-ib-repo', which is NOT the repo of the scm declared in the pipeline wait 5 minutes the job runs.
            Hide
            roidelapluie Julien Pivotto added a comment - - edited

            I even tried to add the hudson.plugins.git.extensions.impl.IgnoreNotifyCommit() extention without success.

            EDIT: confirmed that it does not work

            Show
            roidelapluie Julien Pivotto added a comment - - edited I even tried to add the hudson.plugins.git.extensions.impl.IgnoreNotifyCommit() extention without success. EDIT: confirmed that it does not work
            roidelapluie Julien Pivotto made changes -
            Attachment wa.png [ 35208 ]
            Hide
            roidelapluie Julien Pivotto added a comment - - edited

            squalou jenkins A workaround that might work:

            EDIT: confirmed that it does not work

            Show
            roidelapluie Julien Pivotto added a comment - - edited squalou jenkins A workaround that might work: EDIT: confirmed that it does not work
            roidelapluie Julien Pivotto made changes -
            Attachment wa.png [ 35208 ]
            roidelapluie Julien Pivotto made changes -
            Attachment wa.png [ 35209 ]
            Hide
            roidelapluie Julien Pivotto added a comment -

            "(and yes, I know, polling is evil, whenever I can I have triggers configured on modern scm to push jobs, but sometimes it's just not possible, believe me you don't want to know all the why's)"

            It is not evil. We use polling without schedule (https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-Pushnotificationfromrepository) so it is more pushing than polling, and still have the problem.

            Show
            roidelapluie Julien Pivotto added a comment - "(and yes, I know, polling is evil, whenever I can I have triggers configured on modern scm to push jobs, but sometimes it's just not possible, believe me you don't want to know all the why's)" It is not evil. We use polling without schedule ( https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-Pushnotificationfromrepository ) so it is more pushing than polling, and still have the problem.
            Hide
            munkyboy Mike added a comment -

            I ran into this problem as well. I found a workaround for my setup.

            I'm using bitbucket which offers a ssh and http clone url for repos. For the global library config, I use the http clone url. For the actual job tied the library (and corresponding bitbucket hook), I use the ssh url.

            Show
            munkyboy Mike added a comment - I ran into this problem as well. I found a workaround for my setup. I'm using bitbucket which offers a ssh and http clone url for repos. For the global library config, I use the http clone url. For the actual job tied the library (and corresponding bitbucket hook), I use the ssh url.
            jglick Jesse Glick made changes -
            Link This issue duplicates JENKINS-41497 [ JENKINS-41497 ]
            jglick Jesse Glick made changes -
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Resolved [ 5 ]
            mathieulaude Mathieu LL made changes -
            Attachment image-2017-03-23-18-16-01-313.png [ 36752 ]
            Hide
            mathieulaude Mathieu LL added a comment -

            Workaround that works for me is Additional Behaviours "Don't trigger a build on commit notifications" on the Global Pipeline Libraries configuration :

            Show
            mathieulaude Mathieu LL added a comment - Workaround that works for me is Additional Behaviours "Don't trigger a build on commit notifications" on the Global Pipeline Libraries configuration :
            Hide
            lordjaxom Sascha Volkenandt added a comment -

            Can pleeease someone finally fix this?

            Especially when pipeline libraries are under heavy development, changes triggering ALL builds makes it impossible to work efficiently. Since "don't trigger a build on commit notifications" isn't available anymore and we can not use push notifications, there is no workaround.

            Show
            lordjaxom Sascha Volkenandt added a comment - Can pleeease someone finally fix this? Especially when pipeline libraries are under heavy development, changes triggering ALL builds makes it impossible to work efficiently. Since "don't trigger a build on commit notifications" isn't available anymore and we can not use push notifications, there is no workaround.
            Hide
            dolphy David Crouch added a comment - - edited

            Confirmed that poll SCM jobs are still triggered by every change to a shared library. What's the way forward on this? There are several duplicate JIRAs which describe this issue, but I don't see any open, active ones. Does this one need to be reopened, or does a new Major/Critical Bug need to be written?

            Show
            dolphy David Crouch added a comment - - edited Confirmed that poll SCM jobs are still triggered by every change to a shared library. What's the way forward on this? There are several duplicate JIRAs which describe this issue, but I don't see any open, active ones. Does this one need to be reopened, or does a new Major/Critical Bug need to be written?
            philmcardlecg Phil McArdle made changes -
            Attachment scm_config.png [ 40065 ]
            Hide
            philmcardlecg Phil McArdle added a comment -

            I don't want to diminish your obvious issue, but the fix for JENKINS-41497 fixed this for a lot of us. As an example, my SCM config looks like the following, if you want to compare differences (if there are any):

            Show
            philmcardlecg Phil McArdle added a comment - I don't want to diminish your obvious issue, but the fix for JENKINS-41497 fixed this for a lot of us. As an example, my SCM config looks like the following, if you want to compare differences (if there are any):
            externl Joe George made changes -
            Link This issue relates to JENKINS-47756 [ JENKINS-47756 ]
            Hide
            mcrooney mcrooney added a comment - - edited

            Still seeing this issue, even with workflow-cps-global-lib 2.9 (and Jenkins 2.89.2), and it sounds like others are as well. I've verified that "Include @Library changes in job recent changes" is unchecked, and yet pushes are still triggering new builds of every job that uses them for each commit (not just one time after the fix). Obviously incredibly invasive to have potentially dozens or hundreds of jobs take up all your executors when you update your global library.

            Show
            mcrooney mcrooney added a comment - - edited Still seeing this issue, even with workflow-cps-global-lib 2.9 (and Jenkins 2.89.2), and it sounds like others are as well. I've verified that "Include @Library changes in job recent changes" is unchecked, and yet pushes are still triggering new builds of every job that uses them for each commit (not just one time after the fix). Obviously incredibly invasive to have potentially dozens or hundreds of jobs take up all your executors when you update your global library.
            mcrooney mcrooney made changes -
            Resolution Duplicate [ 3 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            tario Patrick Ruckstuhl added a comment -

            Still seeing this as well, what I found interesting is that it seems to check for the current version on the SLAVE which doesn't make sense (our jobs pick slave depending on availability so they will not always run on the same node.)

            Show
            tario Patrick Ruckstuhl added a comment - Still seeing this as well, what I found interesting is that it seems to check for the current version on the SLAVE which doesn't make sense (our jobs pick slave depending on availability so they will not always run on the same node.)
            Hide
            mrkita Morgan Kita added a comment -

            I have the same behavior, where my library is integrated into my main code repository.

            In our Jenkins we have build jobs that are based off of multiple branches, and in each job where the library is included (the master version of the same repo by default), there are two entries in the polling log. One for the Library (at master version), and one for the actual checkout in the pipeline definition.

            This is a big problem, because the polling is marked as run for the library entry, but if we the pipeline checks out a different branch (and polls on it as is intended), it always returns that there are changes.

            This leads to infinitely triggered builds as it never updates the status properly.

            I could pull out the library code into it's own repo, but I assume that means it will still show up in the polling log, which it should not.

            I have unchecked the "Include @Library changes in job recent changes" flag in the global library configuration and since we use the "library step", I have set changelog: false in all the files which use it.

            Show
            mrkita Morgan Kita added a comment - I have the same behavior, where my library is integrated into my main code repository. In our Jenkins we have build jobs that are based off of multiple branches, and in each job where the library is included (the master version of the same repo by default), there are two entries in the polling log. One for the Library (at master version), and one for the actual checkout in the pipeline definition. This is a big problem, because the polling is marked as run for the library entry, but if we the pipeline checks out a different branch (and polls on it as is intended), it always returns that there are changes. This leads to infinitely triggered builds as it never updates the status properly. I could pull out the library code into it's own repo, but I assume that means it will still show up in the polling log, which it should not. I have unchecked the "Include @Library changes in job recent changes" flag in the global library configuration and since we use the "library step", I have set changelog: false in all the files which use it.
            Hide
            skp SK added a comment -

            Can someone finally fix this please? It is really annoying, especially because the "Include @Library changes in job recent changes" option has no effect.

            Everytime I work on my shared library all multibranch pipeline jobs are going to run.

            Show
            skp SK added a comment - Can someone finally fix this please? It is really annoying, especially because the "Include @Library changes in job recent changes" option has no effect. Everytime I work on my shared library all multibranch pipeline jobs are going to run.
            Hide
            jackiexiao Jackie Xiao added a comment -

            Also facing this issue, we have lots of microservice CI/CD jobs configured, which depend on the shared library, any change made to the shared lib will trigger all downstream jobs.

            Looking forward to the fix.

            Show
            jackiexiao Jackie Xiao added a comment - Also facing this issue, we have lots of microservice CI/CD jobs configured, which depend on the shared library, any change made to the shared lib will trigger all downstream jobs. Looking forward to the fix.
            Hide
            eocampos Eliseo Ocampos added a comment -

            For everyone who may still facing this problem, please refer to the workaround mentioned here. I can confirm it solves the problem.

            Show
            eocampos Eliseo Ocampos added a comment - For everyone who may still facing this problem, please refer to the workaround mentioned here . I can confirm it solves the problem.
            Hide
            brianjenkins Brian Villanueva added a comment -

            Running a full pipeline might take a long time... especially if you have 10s or 100s that are affected by the issue. Does anyone know if there's a way to alter the config proactively (manually) via the job's XML file?

            Show
            brianjenkins Brian Villanueva added a comment - Running a full pipeline might take a long time... especially if you have 10s or 100s that are affected by the issue. Does anyone know if there's a way to alter the config proactively (manually) via the job's XML file?
            Hide
            chris_knight Chris Knight added a comment -

            "Include @Library changes in job recent changes" did fix this issue for us.  However, importantly, we had to restart our Jenkins server for this to take effect. 

            Show
            chris_knight Chris Knight added a comment - "Include @Library changes in job recent changes" did fix this issue for us.  However, importantly, we had to restart our Jenkins server for this to take effect. 
            Hide
            richmond Rich added a comment -

            For me, "Include @Library changes in job recent changes" did stop the changes from appearing in change log but a change in shared library is still triggering the build.

            Show
            richmond Rich added a comment - For me, "Include @Library changes in job recent changes" did stop the changes from appearing in change log but a change in shared library is still triggering the build.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              squalou squalou jenkins
              Votes:
              39 Vote for this issue
              Watchers:
              56 Start watching this issue

                Dates

                Created:
                Updated: