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

    XMLWordPrintable

    Details

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

      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
            swtch3k Cenk Tosun added a comment - - edited

            valide workaround for me was to add an additional behavior at the pipeline definition for the jenkinsfile or at the shared library repo definition, where to use ignore certain path with an inclusion of "ignoreRepo". no more additional builds. hope that bug get fixed or the option will disabled...

            Show
            swtch3k Cenk Tosun added a comment - - edited valide workaround for me was to add an additional behavior at the pipeline definition for the jenkinsfile or at the shared library repo definition, where to use ignore certain path with an inclusion of "ignoreRepo". no more additional builds. hope that bug get fixed or the option will disabled...
            Hide
            wbrode William Brode added a comment -

            Cenk Tosun another solution to your issue is to use "lightweight" checkout when defining the Jenkinsfile SCM.  I think it was intended behavior to allow polling on changes to the jenkinsfile scm - but lightweight will disable that (if you are using an SCM that supports it).

            Show
            wbrode William Brode added a comment - Cenk Tosun another solution to your issue is to use "lightweight" checkout when defining the Jenkinsfile SCM.  I think it was intended behavior to allow polling on changes to the jenkinsfile scm - but lightweight will disable that (if you are using an SCM that supports it).
            Hide
            doronshai Doron Shai added a comment -

            William Brode I do not see that the lightweight checkout actually solve this issue.

            I do not understand why and how this issue is still open. this is a MAJOR problem with Jenkins....

            Show
            doronshai Doron Shai added a comment - William Brode I do not see that the lightweight checkout actually solve this issue. I do not understand why and how this issue is still open. this is a MAJOR problem with Jenkins....
            Hide
            swtch3k Cenk Tosun added a comment -

            William Brode as Doron Shai has already said, this unfortunately does not help to solve the problem...

            Show
            swtch3k Cenk Tosun added a comment - William Brode  as Doron Shai has already said, this unfortunately does not help to solve the problem...
            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 .)          

              People

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

                Dates

                • Created:
                  Updated: