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

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.

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.

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.

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

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?

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

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.

In our case we hade changelogs for global shared libraries enabled but wanted to disable them to avoid rebuilds on library changes. However, doing so made all jobs which currently are failing, entering a infinite build loop due to scm poll. I have figured out that the the scm poll seems to always consider all repositories with changelog/state of the last sucessfull build. This can even be a build you don't see in the web interface. I found following cure:

1. Go to the SCM Poll log of the job and find the "old" state (For us this is subversion: "changed from <xxxxx>")
2. Find file "permalinks" in  ${JENKINS_HOME}/jobs/<affected project>/builds
3. Within that file get the build number of last successfull build
4. Edit ${JENKINS_HOME}/jobs/<affected project>/builds/<build_nr>/build.xml. (Probably make  copy of that file before) In that file, find tag "revisionStates". This tag will have subtags "entry" were one of this subtags will match the affected repo and "old state" determined above. Remove the entire entry. Save file.

May be caused by https://issues.jenkins.io/browse/JENKINS-71127