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

Poll SCM and Timer triggers include "Changes" for a Pipeline for any/all Shared Libraries

    Details

    • Similar Issues:
    • Sprint:
      Pipeline - July/August

      Description

      I noticed this while filing another ticket (JENKINS-41496), but the "Changes" view for the Pipeline run for this project "azure" has the "wrong commits" shown. See the screenshots for more.

      What basically appears to be happening is that any change to a Shared Library will result in newly triggered Pipelines which have "Poll SCM" configured. Pipelines which configure a timer will also have Changes from the Shared Library listed when it executes again.

      I think listing the Shared Library commits in "Changes" is acceptable, but triggering based on an SCM Poll for a Pipeline is very confusing behavior and IMHO incorrect behavior.

      As a shared tooling team, I would not expect my Shared Library changes to trigger a bunch of Pipelines for projects depending on them.

        Attachments

          Issue Links

            Activity

            Hide
            delphym Daniel Mladek added a comment - - edited

            Just would like to confirm, that I'm observing this undesirable behaviour too on Jenkins v2.161 and all the relevant pipeline plugins (up-to-date). All source code including Jenkinsfiles are in SVN, shared libs in Git/Bitbucket.

             

            Nearly after month of migrating legacy builds to new pipelines and going through the loop of learning and refactoring my Jenkinsfiles to make them leaner and started using a [shared library|https://jenkins.io/doc/book/pipeline/shared-libraries/], each time I do a change in a shared lib, it triggers all the pipeline jobs. It's really nightmare.

             

            I understand that there might be a need for this behaviour if a sort of part of a build script has been changed, to validate the rest of the code it is still buildable, OTOH if you're in a building stage of setting up your build system, this is incredible annoying. (For the same reason, I'm almost thinking to setup external repo just for the Jenkinsfiles to avoid unnecessary triggers of build jobs when modified Jenkinsfile in SCM. Having it inside the job configuration or using old fashioned freestyle jobs, exactly achieve this, but without additional benefits of using pipelines.)

             

            So ideally, this behaviour would be configurable (like as it is now for Include @Library changes in job recent changes.)

             

             

             

             

             

            Show
            delphym Daniel Mladek added a comment - - edited Just would like to confirm, that I'm observing this undesirable behaviour too on Jenkins v2.161 and all the relevant pipeline plugins (up-to-date). All source code including Jenkinsfiles are in SVN, shared libs in Git/Bitbucket.   Nearly after month of migrating legacy builds to new pipelines and going through the loop of learning and refactoring my Jenkinsfiles to make them leaner and started using a [shared library| https://jenkins.io/doc/book/pipeline/shared-libraries/ ], each time I do a change in a shared lib, it triggers all the pipeline jobs. It's really nightmare.   I understand that there might be a need for this behaviour if a sort of part of a build script has been changed, to validate the rest of the code it is still buildable, OTOH if you're in a building stage of setting up your build system, this is incredible annoying. (For the same reason, I'm almost thinking to setup external repo just for the Jenkinsfiles to avoid unnecessary triggers of build jobs when modified Jenkinsfile in SCM. Having it inside the job configuration or using old fashioned freestyle jobs, exactly achieve this, but without additional benefits of using pipelines.)   So ideally, this behaviour would be configurable (like as it is now for Include @Library changes in job recent changes .)          
            Hide
            doronshai Doron Shai added a comment -

            MOVING TO GITLAB CI - THANKS FOR THE AMAZING SUPPORT

            Show
            doronshai Doron Shai added a comment - MOVING TO GITLAB CI - THANKS FOR THE AMAZING SUPPORT
            Hide
            jackiexiao Jackie Xiao added a comment -

            No matter how many new features being added to Jenkins, lack of support and issue fixing for such basic issues will eventually drove users away.

            Goodbye Jenkins

            Show
            jackiexiao Jackie Xiao added a comment - No matter how many new features being added to Jenkins, lack of support and issue fixing for such basic issues will eventually drove users away. Goodbye Jenkins
            Hide
            gordin Christoph Vogtländer added a comment -

            I'm also affected by this issue running Jenkins ver. 2.176.2 with "Pipeline: Shared Groovy Libraries" version 2.14

            I just recently switched to shared libs from internal workflowLibs.git. I added a global shared library using Subversion defined with "Load implicitly: true", "Allow default version to be overridden: true" and "Include @Library changes in job recent changes: true".
            After the global library was used in the build for the first time, subsequent builds are now triggered whenever something changes in the global library.

            I was not able to resolve this by simply deactivating "Include @Library changes in job recent changes". Still, builds were triggered for every commit in the shared lib. Only after a Jenkins restart ("Include @Library changes in job recent changes" is still false) the job is no longer triggered.

            Why are polling and changelog bound to each other in shared libraries in the first place? In the "checkout" step these are two different options (or am I misreading something?).

            In my case, the project that is triggered does NOT poll the SCM but is configured to only react on push notifications. So, this might be a different issue? Should I open a new bug report?

            Show
            gordin Christoph Vogtländer added a comment - I'm also affected by this issue running Jenkins ver. 2.176.2 with "Pipeline: Shared Groovy Libraries" version 2.14 I just recently switched to shared libs from internal workflowLibs.git. I added a global shared library using Subversion defined with "Load implicitly: true", "Allow default version to be overridden: true" and "Include @Library changes in job recent changes: true". After the global library was used in the build for the first time, subsequent builds are now triggered whenever something changes in the global library. I was not able to resolve this by simply deactivating "Include @Library changes in job recent changes". Still, builds were triggered for every commit in the shared lib. Only after a Jenkins restart ("Include @Library changes in job recent changes" is still false) the job is no longer triggered. Why are polling and changelog bound to each other in shared libraries in the first place? In the "checkout" step these are two different options (or am I misreading something?). In my case, the project that is triggered does NOT poll the SCM but is configured to only react on push notifications. So, this might be a different issue? Should I open a new bug report?
            Hide
            yrsurya suryatej yaramada added a comment -

            Even we are facing same issue , opened a ticket - https://issues.jenkins-ci.org/browse/JENKINS-52816

            Show
            yrsurya suryatej yaramada added a comment - Even we are facing same issue , opened a ticket -  https://issues.jenkins-ci.org/browse/JENKINS-52816

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                rtyler R. Tyler Croy
              • Votes:
                71 Vote for this issue
                Watchers:
                80 Start watching this issue

                Dates

                • Created:
                  Updated: