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
            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
            Hide
            allan_burdajewicz Allan BURDAJEWICZ added a comment - - edited

            Is this still happening even after jobs are rebuilt at least once (see my comment above) ?

            If still hitting the problem, https://issues.jenkins-ci.org/browse/JENKINS-61415 (workflow-job:2.37) may help as it does not require a rebuild anymore. (nor a restart of Jenkins)

            Show
            allan_burdajewicz Allan BURDAJEWICZ added a comment - - edited Is this still happening even after jobs are rebuilt at least once (see my comment above) ? If still hitting the problem, https://issues.jenkins-ci.org/browse/JENKINS-61415 (workflow-job:2.37) may help as it does not require a rebuild anymore. (nor a restart of Jenkins)

              People

              • Assignee:
                Unassigned
                Reporter:
                rtyler R. Tyler Croy
              • Votes:
                75 Vote for this issue
                Watchers:
                84 Start watching this issue

                Dates

                • Created:
                  Updated: