Upgraded to 2.9, but still experience the same problem. See attached screenshot of the configuration of the global library and of one of the dozens of triggered builds.


I can confirm I do not see the library commit in the triggered builds changelogs, but that seemed a minor problem with respect to this ticket's description, which is not to trigger all jobs everywhere.

I tried switching Modern SCM from Git to Github and back, and recreating the configuration of the global library fearing some state was lingering from the previous version of the plugin.

Sample output from one of the triggered builds demonstrating the commit message is coming from the shared library: https://gist.github.com/giorgiosironi/ef4f326d0e959cbd826d9a6cef769b44

Rolled back to the internal /workflowLibs.git repository approach, the only workaround I know.

Doesn't solve the problem - for some reason when I push to the Github equivalent of the internal /workflowLibs.git (used as a backup: https://github.com/elifesciences/elife-jenkins-workflow-libs), a web hook triggers all builds again. Now going through organizational and repository hooks to check what's happening.

The log says:

Sep 25, 2017 9:55:48 AM INFO org.jenkinsci.plugins.github_branch_source.PushGHEventSubscriber onEvent

Received PUSH for https://github.com/elifesciences/elife-jenkins-workflow-libs from 192.30.252.40 ⇒ http://ci--alfred.elifesciences.org:8080/github-webhook/

Sep 25, 2017 9:55:48 AM INFO com.cloudbees.jenkins.GitHubPushTrigger$1 run

SCM changes detected in library-api-validator-php. Triggering #22

Sep 25, 2017 9:55:49 AM INFO com.cloudbees.jenkins.GitHubPushTrigger$1 run

SCM changes detected in library-patterns-php. Triggering #434

Sep 25, 2017 9:55:49 AM INFO com.cloudbees.jenkins.GitHubPushTrigger$1 run

Since the web hook is organization-wide, I don't even know how does it understand that the repository is a global workflow library. I have gone through workspaces to delete the ...@libs folders to no avail.

Deleted all workspaces too, no change. The log of a triggered build continues to say:

 > git ls-remote -h git@github.com:elifesciences/elife-jenkins-workflow-libs.git # timeout=10
Found 1 remote heads on git@github.com:elifesciences/elife-jenkins-workflow-libs.git
[poll] Latest remote head revision on refs/heads/master is: 9f5110ead60321557cdc0e5394ec299d70983938
Using strategy: Default
[poll] Last Built Revision: Revision 966f0ebb926fbe6e2db5d2de68a86aec4ff86676 (refs/remotes/origin/develop)

and I don't know where it's getting that repository URL from.

I have found these references:

elife@ci--alfred:/var/lib/jenkins$ grep -r elife-jenkins-workflow-libs jobs/test-journal/builds/1056/build.xml                            
        <string>git@github.com:elifesciences/elife-jenkins-workflow-libs.git</string>
            <url>git@github.com:elifesciences/elife-jenkins-workflow-libs.git</url>

which are on a previous build rather than on the jobs definition, it is possible they are used to determine whether to trigger the job again. Will try to remove it on a test job.

To delete these references, I found out you have to run at least 1 (successful?) build for each job without the global pipeline library being defined in Global Settings. This seems to remove from the jobs/ metadata the reference to the external repository, so that when the Github hook triggers it is ignored. I am now running all builds once to clear all references before I am able to make changes to the library and push it to /workflowLibs.git.

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?

dolphy possibly a new one (with repro details) cc abayer

As far as I can tell, the fix works. I noticed that existing jobs will need to be built at least once for this to take effect. This will "fix" the metadata recorded the SCM used. So when you upgrade to that version, the first next change to the shared library code might still triggers many jobs. Next changes will not.

ah thanks allan_burdajewicz!

cc dolphy

allan_burdajewicz michaelneale

You're right, and I'm wrong! I had based my comment solely off of seeing the jobs kick again, but never verified that they will continually kick. After the first time, they no longer trigger on a shared library commit.

Sorry for the hasty assumption, and thanks!

The global configuration option only for works for implicitly loaded libraries. If I include a library with the library step, I have to specify

library identifier: "MyLibrary", changelog: false

I would expect the default behavior

library "MyLibrary"

to be controlled by the global LibraryConfiguration option. As it is, I have to edit a large number of Jenkinsfiles to enable the new feature.

It seems like my expected behavior might have been intended originally. In the implementation in LibraryStep.java

public static class Execution extends AbstractSynchronousNonBlockingStepExecution<LoadedClasses> {
    @Override protected LoadedClasses run() throws Exception {
        // ...
        Boolean changelog = step.getChangelog(); // returns default value LibraryStep.changelog = true, if not provided
        // ...
        changelog = cfg.defaultedChangelogs(changelog); // returns changelog if != null, else global configuration option
        // ...
    }
}

a function is called that loads the global configuration value if the argument is null, but due to the default initialization, this statement only has effect if changelog = null is specified explicitly. However, a comment for LibraryStep.setChangelog states: default to including changes of the library in job recent changes.

Is this working as intended or should I open a PR for this?

mnsa do you mind opening that as a new feature JIRA for this and a PR that goes with it (if you want to) - and could be discussed there (or at least the ticket, where can be discussed). Changing default usually needs discussion but it seems reasonable in this case that the default is probably not right. 

With workflow-cps-global-lib 2.9 still seeing that jobs are re-built multiple times, with the option unchecked to include library changes in the config UI. I would agree that changing the default makes sense in this case because it is very unintuitive and can cause pretty large issues to your cluster throughput and stability, while if you wanted it and it gets turned off, you can easily turn it on.

From JENKINS-41497, "The global configuration option only for works for implicitly loaded libraries." For non-implicit libraries, is it expected that we have to set
changelog: false
..in every Jenkinsfile? If so, then the global setting should be a child checkbox under the implicit checkbox.

I opened issue JENKINS-48487 for this specific problem. It is actually only a problem of the the library step, using the '@Library' decorator, it works fine. For the library step you would have to specify changelog: false in every Jenkinsfile (and change it to true, if you should change your mind later on). Since it works for the decorator syntax, I don't think it should be a child checkbox of the implicit checkbox. I filed it as a bug because the behavior is different between the decorator and the step.

I see this issue once again with Jenkins 2.107.2, on 2.107.1 it is working just fine

This bug is still present on version 2.116. I found that the workaround mentioned here is the way to go for the moment. Thanks allan_burdajewicz!

Hello and sorry for being bit thick, but where is this "global configuration" located and changed?

I am trying to have implicitly loaded library for certain folder, but I cant figure how to stop the builds triggering continuously from shared lib commits.

Go to Manage Jenkins -> Configure System and there find the section "Global Pipeline Libraries"

"Dont trigger build a build on commit notifications" this setting for the library should stop the triggering?

This is what I already tested, and no matter if I let jobs trigger and build, they will trigger second, third and fourth time as well from commits to shared library.

lakeend please pay close attention to this comment and this other comment above.

I am confused as to what the "fix" is. I enabled the setting "Dont trigger build a build on commit notifications" for all our Jenkins jobs and they still get triggered whenever the global library SCM has a commit and this keeps happening after the first time. Do I need to remove the global library and re-add it again for this to work?

Seeing this exact issue on Jenkins 2.150.1, Build Pipeline 1.5.8. Have a global library set up in one repo/configured under Global Configuration, and a multibranch job that polls a different repo for changes to specific branches. Upon committing anything to any file in the global library repo, the multibranch job is triggered. I've read every thread I can find on the issue but cannot figure out how to not have jobs triggered when committing changes to the global library repo. It's basically unusable at this point, as I can't continue to trigger all jobs over and over. 

whatsdevops not sure if that is related to this issue: but I think that may be possible by using "when" and looking at the cause/trigger. So when global libraries are updated, the job will run, but terminate early (green) as it can skip the rest of the build. Kind of a work around. 

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

swtch3k 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).

wbrode 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....

wbrode as doronshai has already said, this unfortunately does not help to solve the problem...

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.)

MOVING TO GITLAB CI - THANKS FOR THE AMAZING SUPPORT

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

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?

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

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)

in version 2.9 of workflow-cps-global-lib-plugin you added "allow excluding shared libraries from changelogs" as part of this commit https://github.com/jenkinsci/workflow-cps-global-lib-plugin/commit/64df779249ac69981a17f46e2698791fe95fa06d , but you never mentioned of how to do it in jenkins declarative pipeline?

well, this is the syntax of loading shared library into the pipeline

libraries {
  lib('some-library')
}

but I couldn't find any way to add the annotation of changelog=false in the jenkins declarative pipeline syntax. any idea how?

 and I couldn't find anything here: https://www.jenkins.io/doc/book/pipeline/shared-libraries/

some examples can be found here for jenkins scripted pipeline: https://stackoverflow.com/questions/46735908/jenkins-pipeline-global-pipeline-library-updates-show-up-in-jobs-list-of-rece
 

dnusbaum timja any chance that you can help here?

You can configure it in the global config (which is what we do) no idea about in the pipeline

Hi timja , thank you for your reply. I forgot to mention it but I already tried to configure it in the global config but it's not affect on my declarative pipeline which located in github organization. So in case that there are new commits in the shared library git repo I see those changes as part of the pipeline which can be confusing or affect the change set array that I use to detect what files has been changed 

dordor We have the same issue with declarative pipelines where I can't figure out how to turn off changelog. The global configuration doesn't seem to work. It's turned off but changelogs is still included for shared libraries.
We're using v2.17 of workflow-cps-global-lib-plugin.

I am facing similar issue. When I unselect 'Include @Library changes in job recent changes' and restart Jenkins, changelog does not show changes made to shared library but any change in shared library is still triggering the build.

I still can't find a way to disable the change log for the shared library changes (which is not relevant for me) in declerative pipelines

is seems that the default is true

apperantly thhis is the relevant code:

    private Boolean changelog = true;
    ...
    // default to including changes of the library in job recent changes
    @DataBoundSetter public void setChangelog(Boolean changelog) {
        this.changelog = changelog;
    }

https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/libs/LibraryStep.java#L111-L114

and this

    static void doRetrieve(String name, boolean changelog, @Nonnull SCM scm, FilePath target, Run<?, ?> run, TaskListener listener) throws Exception {
        ...
        delegate.setChangelog(changelog);

https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/libs/SCMSourceRetriever.java#L139

more info here: https://issues.jenkins.io/browse/JENKINS-41497?focusedCommentId=394574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-394574

dnusbaum any chance that you can have a look?

I have the same issue in declarative pipeline with fresh install of 2.263.3.

With a multibranch declarative pipeline (Bitbucket Source Plugin) my job changelog contains very confusingly Git revision changes for my global pipeline library (loaded via git scm), but lists no changes from Bitbucket.

Following advice I have unticked:

And also tried changing my Jenkinsfile annotation to:

@Library(value='my-lib', changelog=false)

But neither prevents the details appearing on clicking on a the build page for a completed job.

I get GIt revision details on every job run from the last library update - irrespective if the library has been updated from the last job or not.

Also I note that the declarative way of loading a libraries - using the libraries directive has no provision for setting the changelog parameter, as evidenced by this note in the source code:

https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/15978cd172a8d34e2cd6bf8a6bfeaa5514d44dad/pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/ModelParser.groovy#L743

As Bitbucket doesn't use polling I don't have the problem of my jenkins library kicking off builds.

FWIW - I think both kicking off builds and even reporting library changes should be turned off by default, it's taken me a fair bit of head-scratching to even understand where the commit ids came from - I had just assumed they were from my project source control for months.

My company recently moved from GitLab to GitHub and this exact issue is happening now where it triggers all consumers of our shared library. The problem is that we have such a large consumer base that it is literally triggering 100s of pipeline jobs. We have tried everything like others have mentioned with adding additional behaviours to the lib pipeline definition: "Don't trigger a build on commit notifications", "Polling ignored from certain users", "dot not check Include @Library changes in job recent changes" and nothing works. We are upgrading our Jenkins and plugins this weekend which is a little dated but I don't think it will resolve anything based on the open issues. I'm hoping some sort of solution is found because this is not ideal and we are having to do some creative things to get by at the moment 

gartoty, I had similar issues. Try this:

1. Did you restart Jenkins after you made changes to the Shared Library definition ? If not, do it now.
2. All your pipeline jobs which are getting triggered, will need reset of 'GitHub hook trigger for GITScm polling' i.e. go to each job, disable the trigger, save job, enable the trigger, save job.

That should fix. You may try #2 on a few jobs first before doing it for all 100s of them.

It is March 2023, five years after the bug was reported.
I come here every time I update a global library, and Jenkins launches more than 100 projects, blocking the servers for hours.

The fact that such a fundamental bug has not been fixed for such a long period of time frightens me every time and I think about a change of CI software.

If it weren't for the 100+ pipelines, I wouldn't want to rewrite ....

debugbug - is this not solved by 'unchecking' the option for 'Include @Library changes in job recent changes' in the section 'Global Pipeline Libraries' under Manage Jenkins -> Configure?

No, I switched to Legacy SCM and unchecked the "Include @Library..." option.

I have rebuilt all the projects but it still does not work and is triggered every time.

SCM is Git(lab)

Found the issue https://issues.jenkins.io/browse/JENKINS-71127