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-68675] Use of Global Libraries breaks commit URLs

          Ulli Hafner added a comment -

          Ulli Hafner added a 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?

          Ulli Hafner added a 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.

          Ulli Hafner added a 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.

          Nick Jones added a 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.

           

          Nick Jones added a 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.  

          Ulli Hafner added a 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

          Ulli Hafner added a 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

          Nick Jones added a 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.

          Nick Jones added a 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.

          Jan added a comment - - edited

          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.

          Jan added a comment - - edited 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.

          Andrew added a 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.

          Andrew added a 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.

          Ulli Hafner added a 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.

          Ulli Hafner added a 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.

            Unassigned Unassigned
            medianick Nick Jones
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: