[JENKINS-68675] Use of Global Libraries breaks commit URLs

[jenkins-infra-bot]

We use a Global Library for common pipeline commands, and it's referenced at the top of our Jenkinsfiles (e.g., @​Library('MyLibrary')). Upon adding mineRepository(), the first thing I noticed was an additional SCM Forensics link on the left menu for the build – one corresponded to the Global Library's repository, and one to the actual repository being built. I was able to remove the extra SCM Forensics entry by adding an scm parameter to filter the SCM in use. However, even having done so, when clicking a particular commit from the Details page (either the "file churn graph" or the list of commits at the bottom), I am sent to a URL for the Global Library's repository but with the actual repository's commit SHA (leading to a 404, not surprisingly).

I think it would be ideal if Global Libraries were entirely ignored by this plugin, but barring that, at the very least it should generate the correct SCM commit URLs for the repository specified by the scm parameter.

---

Originally reported by medianick, imported from: Use of Global Libraries breaks commit URLs

• status: Open
• priority: Minor
• component(s): forensics-api-plugin, git-forensics-plugin
• label(s): help-wanted
• resolution: Unresolved
• votes: 0
• watchers: 5
• imported: 20260107-220949

Raw content of original issue

We use a Global Library for common pipeline commands, and it's referenced at the top of our Jenkinsfiles (e.g., @Library('MyLibrary')). Upon adding mineRepository(), the first thing I noticed was an additional SCM Forensics link on the left menu for the build – one corresponded to the Global Library's repository, and one to the actual repository being built. I was able to remove the extra SCM Forensics entry by adding an scm parameter to filter the SCM in use. However, even having done so, when clicking a particular commit from the Details page (either the "file churn graph" or the list of commits at the bottom), I am sent to a URL for the Global Library's repository but with the actual repository's commit SHA (leading to a 404, not surprisingly). 

I think it would be ideal if Global Libraries were entirely ignored by this plugin, but barring that, at the very least it should generate the correct SCM commit URLs for the repository specified by the scm parameter.

[jenkins-infra-bot]

drulli:

• Original comment link
• Raw content of original comment:

  Indeed, the decorator should use the selected SCM in https://github.com/jenkinsci/forensics-api-plugin/blob/master/src/main/java/io/jenkins/plugins/forensics/miner/ForensicsViewModel.java#L104
  
  Interested in adding a PR?
  

Indeed, the decorator should use the selected SCM in https://github.com/jenkinsci/forensics-api-plugin/blob/master/src/main/java/io/jenkins/plugins/forensics/miner/ForensicsViewModel.java#L104

Interested in adding a PR?

[jenkins-infra-bot]

drulli:

• Original comment link
• Raw content of original comment:

  
  I think it would be ideal if Global Libraries were entirely ignored by this plugin, but barring that, at the very least it should generate the correct SCM commit URLs for the repository specified by the scm parameter.
  
  Do you have an idea how to achieve? I did not find any Jenkins API method which makes a decision if an SCM is for sources and code or for libraries. They are currently simply provided in an unsorted list.
  

I think it would be ideal if Global Libraries were entirely ignored by this plugin, but barring that, at the very least it should generate the correct SCM commit URLs for the repository specified by the scm parameter.

Do you have an idea how to achieve? I did not find any Jenkins API method which makes a decision if an SCM is for sources and code or for libraries. They are currently simply provided in an unsorted list.

[jenkins-infra-bot]

medianick:

• Original comment link
• Raw content of original comment:

  
  Do you have an idea how to achieve? 
  
  Alas, no. I thought to find something in how Global Libraries are treated differently (like their "Don't trigger a build on commit notifications" setting) but wasn't successful.
  
  
  Interested in adding a PR?
  
  Interested, though maybe not able to. I'm unfamiliar with the code. But I'll take a look if I can.
  
  
  
   
  

Do you have an idea how to achieve?

Alas, no. I thought to find something in how Global Libraries are treated differently (like their "Don't trigger a build on commit notifications" setting) but wasn't successful.

Interested in adding a PR?

Interested, though maybe not able to. I'm unfamiliar with the code. But I'll take a look if I can.

 

[jenkins-infra-bot]

drulli:

• Original comment link
• Raw content of original comment:

  Jesse pointed out that there is some information available that I can use here: https://javadoc.jenkins.io/plugin/scm-api/jenkins/scm/api/SCMRevisionAction.html
  

Jesse pointed out that there is some information available that I can use here: https://javadoc.jenkins.io/plugin/scm-api/jenkins/scm/api/SCMRevisionAction.html

[jenkins-infra-bot]

medianick:

• Original comment link
• Raw content of original comment:

  There's also a different issue with the same root cause: publishCoverage or recordCoverage (from the Code Coverage API plugin) use the Git Forensics plugin, which in turn logs JGit errors referencing the shared library commit (at which it was loaded):
  
  
  [Coverage] [-ERROR-] Errors while reporting code coverage results:
  [Coverage] [-ERROR-] Computing delta information failed with an exception:
  [Coverage] [-ERROR-] org.eclipse.jgit.errors.MissingObjectException: Missing unknown 1db40cd0a900443b9a6d0eabcb23be7081cae24d
  [Coverage] [-ERROR-] 	at org.eclipse.jgit.internal.storage.file.WindowCursor.open(WindowCursor.java:143)
  [Coverage] [-ERROR-] 	at org.eclipse.jgit.lib.ObjectReader.open(ObjectReader.java:216)
  ...a
  
  
  This commit can be seen in the console log when the shared library is first loaded
  
  11:29:48  Loading library ****
  11:29:48  Examining ****
  11:29:48  Attempting to resolve **** as a branch
  11:29:49  Resolved **** as branch **** at revision 1db40cd0a900443b9a6d0eabcb23be7081cae24d
  ...
  
  
  It does not cause the built itself to fail or become unstable, but it's noise in the logs.
  

There's also a different issue with the same root cause: publishCoverage or recordCoverage (from the Code Coverage API plugin) use the Git Forensics plugin, which in turn logs JGit errors referencing the shared library commit (at which it was loaded):

[Coverage] [-ERROR-] Errors while reporting code coverage results:
[Coverage] [-ERROR-] Computing delta information failed with an exception:
[Coverage] [-ERROR-] org.eclipse.jgit.errors.MissingObjectException: Missing unknown 1db40cd0a900443b9a6d0eabcb23be7081cae24d
[Coverage] [-ERROR-] 	at org.eclipse.jgit.internal.storage.file.WindowCursor.open(WindowCursor.java:143)
[Coverage] [-ERROR-] 	at org.eclipse.jgit.lib.ObjectReader.open(ObjectReader.java:216)
...a

This commit can be seen in the console log when the shared library is first loaded

11:29:48  Loading library ****
11:29:48  Examining ****
11:29:48  Attempting to resolve **** as a branch
11:29:49  Resolved **** as branch **** at revision 1db40cd0a900443b9a6d0eabcb23be7081cae24d
...

It does not cause the built itself to fail or become unstable, but it's noise in the logs.

[jenkins-infra-bot]

meiswjn:

• Original comment link
• Raw content of original comment:

  This is breaking "discoverGitReferenceBuild" for us completely. For some reason, it takes the shared libraries last commit instead of the latest commit from the project itself if the same shared library is used within the reference project.
  EDIT: Perhaps it is a different bug? We are lead to the shared library also in the UI. However, in the log the correct project is mentioned but with the wrong commit id.
  

This is breaking "discoverGitReferenceBuild" for us completely. For some reason, it takes the shared libraries last commit instead of the latest commit from the project itself if the same shared library is used within the reference project.
EDIT: Perhaps it is a different bug? We are lead to the shared library also in the UI. However, in the log the correct project is mentioned but with the wrong commit id.

[jenkins-infra-bot]

agar3927:

• Original comment link
• Raw content of original comment:

  Any updates on this? I am also experiencing similar issues...when running a build for a project, I checkout another repository first, yet GitForensics appears to be conflating the latest commit of this unrelated repository with being related to the repository being built. Here's an example log of the build, where <current-repo> is the repo being built and <other-repo> is the unrelated repo that was checked out first:
  
  [GitCheckoutListener] Recording commits of 'git https://<other-repo>'
  [GitCheckoutListener] Found previous build 'Folder/<current-repo>/develop #14' that contains recorded Git commits
  [GitCheckoutListener] -> Starting recording of new commits since '<other-repo-hash-1>'
  [GitCheckoutListener] -> Multiple parent commits found - storing latest commit of local merge '<other-repo-hash-2>'
  [GitCheckoutListener] -> Using parent commit '<other-repo-hash-3>' of local merge as starting point
  [GitCheckoutListener] -> Storing target branch head '<other-repo-hash-4>' (second parent of local merge) 
  [GitCheckoutListener] -> Recorded 200 new commits
  [GitCheckoutListener] -> The latest commit '<other-repo-hash-2>' is a merge commit
  
  When using this to calculate code coverage deltas with the Coverage Plugin for Jenkins, the following output is observed:
  
  [Coverage] [-ERROR-] Errors while reporting code coverage results:
  [Coverage] [-ERROR-] Computing delta information failed with an exception:
  [Coverage] [-ERROR-] org.eclipse.jgit.errors.MissingObjectException: Missing unknown <other-repo-hash-1> 
  
  Reports are then generated with undefined coverage deltas.
  

Any updates on this? I am also experiencing similar issues...when running a build for a project, I checkout another repository first, yet GitForensics appears to be conflating the latest commit of this unrelated repository with being related to the repository being built. Here's an example log of the build, where is the repo being built and is the unrelated repo that was checked out first:

[GitCheckoutListener] Recording commits of 'git https://'
[GitCheckoutListener] Found previous build 'Folder//develop #14' that contains recorded Git commits
[GitCheckoutListener] -> Starting recording of new commits since ''
[GitCheckoutListener] -> Multiple parent commits found - storing latest commit of local merge ''
[GitCheckoutListener] -> Using parent commit '' of local merge as starting point
[GitCheckoutListener] -> Storing target branch head '' (second parent of local merge) 
[GitCheckoutListener] -> Recorded 200 new commits
[GitCheckoutListener] -> The latest commit '' is a merge commit

When using this to calculate code coverage deltas with the Coverage Plugin for Jenkins, the following output is observed:

[Coverage] [-ERROR-] Errors while reporting code coverage results:
[Coverage] [-ERROR-] Computing delta information failed with an exception:
[Coverage] [-ERROR-] org.eclipse.jgit.errors.MissingObjectException: Missing unknown  

Reports are then generated with undefined coverage deltas.

[jenkins-infra-bot]

drulli:

• Original comment link
• Raw content of original comment:

  This issue is about broken commit URLs. Your problem seems to be unrelated to this issue. 
  
  Please create a new issue that contains the relevant information.  
  

This issue is about broken commit URLs. Your problem seems to be unrelated to this issue.

Please create a new issue that contains the relevant information.

[jenkins-infra-bot]

emirboyaci:

• Original comment link
• Raw content of original comment:

  Hi drulli,
  
  Is this something we can have update? This is breaking the blame information for us as well.
  
  Best,
  Emir
  

Hi drulli,

Is this something we can have update? This is breaking the blame information for us as well.

Best,
Emir