-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.277.4
Pipeline: Shared Groovy Libraries 2.19
Pipeline: Multibranch: 2.23
Even when I disable (un marking) the "Include @Library changes in job recent changes" option from the global configuration under Global Pipeline Libraries:
From some reason I still see commit changes from my shared libraries in a different multi branch job that uses declarative pipeline.
sample from the multi branch job declarative pipeline:
pipeline {
libraries {
lib('pipeline-library')
}
...
}
How to reproduce:
- Disable the "Include @Library changes in job recent changes" under global conf
- create standard pipeline job and use declarative pipeline
- import some shared libraries like the sample above
- perform change in your shared libraries and push your changes by creating a new commit
- run your pipeline job
- checkout the job changes and verify that you see commits from the shared libraries which shouldn't be here
I can see that this has been discussed here:
https://issues.jenkins.io/browse/JENKINS-39615
and here
https://issues.jenkins.io/browse/JENKINS-39615
But those tickets are more talking about jobs that are triggered automatically due to changes in shared libraries. While this ticket is more about changes that should not be presented on the job history under the commit list
- relates to
-
JENKINS-41497 Poll SCM and Timer triggers include "Changes" for a Pipeline for any/all Shared Libraries
-
- Reopened
-
-
-
- Open
-
[JENKINS-65649] disable Include @Library changes in job recent changes is not respected
Richard
added a comment - May be caused by https://issues.jenkins.io/browse/JENKINS-71127 
Michael Nazzareno
added a comment - mjdetullio any update about it? or where we can take a look at the code and fix it
Michael Nazzareno
added a comment - mjdetullio any update about it? or where we can take a look at the code and fix it 
Christopher
added a comment - This is a frustrating bug. It doesn't just impact the changelogs, but potentially everything that uses git commits in Jenkins. The GitCommitListener grabs the commits and records the head commit of the pipeline rather than the project, and that gets passed to future builds as the "last recorded HEAD", and passed to tools (such as coverage) looking for the HEAD, so this could break lots of stuff.
The only solution I've managed to find to this is to cache the pipeline library on the controller, which then skips the checkout (usually? I'm not sure whether clearing the cache in order to refresh and get a new version will cache it, or cause the first project build after a cache clear to get messed up again).
If the Jenkins maintainers are having trouble reproducing this, it's probably because their own system has caching turned on (which was the only way I managed to find the workaround - I dug through build logs of Jenkins plugins until I spotted the caching line and guessed it was why there was no GitCheckoutListener logs)
Christopher
added a comment - This is a frustrating bug. It doesn't just impact the changelogs, but potentially everything that uses git commits in Jenkins. The GitCommitListener grabs the commits and records the head commit of the pipeline rather than the project , and that gets passed to future builds as the "last recorded HEAD", and passed to tools (such as coverage) looking for the HEAD, so this could break lots of stuff.
The only solution I've managed to find to this is to cache the pipeline library on the controller, which then skips the checkout (usually? I'm not sure whether clearing the cache in order to refresh and get a new version will cache it, or cause the first project build after a cache clear to get messed up again).
If the Jenkins maintainers are having trouble reproducing this, it's probably because their own system has caching turned on (which was the only way I managed to find the workaround - I dug through build logs of Jenkins plugins until I spotted the caching line and guessed it was why there was no GitCheckoutListener logs) Michael Nazzareno
added a comment - 
The problem is even on the side on final building result. The git build data are coming from shared library. Can someone give some info in what part of jenkins code take a look?
Michael Nazzareno
added a comment -
The problem is even on the side on final building result. The git build data are coming from shared library. Can someone give some info in what part of jenkins code take a look? 
I have this exact issue as well. It is very confusing for the pipeline consumers to see changes that have nothing to do with their repo in their pipeline run UIs.
There is discussion here about disabling the changelog when loading a library, but is there a way to disable the changelog for all pipelines that consume the library, in the library itself? Instead of having to go and modify all consumers?