We don't want to be showing the commits from a shared library in this case. We need to do some testing here and find out why shared library changes are coming through and not the application code. We suspect that we pick the first grouping of change sets and this happens to be the changeset of the shared library in this scenario.
Show only the latest commit from the repository that the pipeline originates from (ie where the Jenkinsfile is changed) that was triggering the pipeline.
Any other commits are to be ignored as part of this. They will show up in the design shown in: https://issues.jenkins-ci.org/browse/JENKINS-39860
I'm using pipelines for a while now and have most of the steps used abstracted away into a pipeline library in a git repository. I now installed blue ocean today and was scrolling through my builds which had all suprisingly the same commit shown:
Turns out this is actually the latest commit of the pipeline library I'm using as seen in the console log:
I would expect this to be the commit of the actually checked out repository.