At the moment warnings-ng doesn't support the git-feature submodule.

      In the log the plugin promts the following error

      Git blame errors:
      no blame results for request <Module/UtilityLib/Source/UtilMath.c - [534]>.
      

      Egit returns null for the request.

       

          [JENKINS-56215] git submodule support

          Tim Schlüter added a comment -

           

          $ git blame Module/UtilityLib/Source/UtilMath.c                      
          fatal: no such path 'Module/UtilityLib/Source/UtilMath.c' in HEAD               
          $ ls Module/UtilityLib/Source/UtilMath.c                               
          Module/UtilityLib/Source/UtilMath.c  
          

           

          Tim Schlüter added a comment -   $ git blame Module/UtilityLib/Source/UtilMath.c fatal: no such path 'Module/UtilityLib/Source/UtilMath.c' in HEAD $ ls Module/UtilityLib/Source/UtilMath.c Module/UtilityLib/Source/UtilMath.c  

          Ulli Hafner added a comment -

          I see. If this is not possible in git then it is not possible in my plugin. I don't see what I can do here

          Ulli Hafner added a comment - I see. If this is not possible in git then it is not possible in my plugin. I don't see what I can do here

          Tim Schlüter added a comment -

          Changing the directory would work

          $ cd Module/UtilityLib/                                                                                                                                      
          $ git blame Source/UtilMath.c                                                                                                                        
          0372016e (userx 2015-08-24 15:43:28 +0200   1) /**@file**********************************************************************                                                                                                               
          76b7d993 (usery 2015-10-13 12:05:32 +0200   2)                                                                                                              
          889358ba (userx 2015-08-24 15:48:29 +0200   3)   Copyright(c) Alle Rechte sowie jede Verfuegungsbefugnis,                                                                                                                                   
          ...

           

          Tim Schlüter added a comment - Changing the directory would work $ cd Module/UtilityLib/ $ git blame Source/UtilMath.c 0372016e (userx 2015-08-24 15:43:28 +0200 1) /**@file********************************************************************** 76b7d993 (usery 2015-10-13 12:05:32 +0200 2) 889358ba (userx 2015-08-24 15:48:29 +0200 3) Copyright(c) Alle Rechte sowie jede Verfuegungsbefugnis, ...  

          Ulli Hafner added a comment -

          Then it should be feasible somehow. GitBlamer needs to be adapted to detect the advanced feature Submodules from the git scm step and then somehow changes the processing of the files.

          Ulli Hafner added a comment - Then it should be feasible somehow. GitBlamer needs to be adapted to detect the advanced feature Submodules from the git scm step and then somehow changes the processing of the files.

          Simon Wright added a comment -

          Simon Wright added a comment - Workaround: disable blaming, see  https://github.com/jenkinsci/warnings-ng-plugin/blob/master/doc/Documentation.md#source-code-blames-for-git-projects

          You're currently doing something like
          "git blame <filepath>/<filename>".
          If you change this behavior to
          "cd <filepath> ; git blame <filename>"
          this would always work for all files correctly.

          (Also this would solve a problem if the warnings come from multiple repos, which are not submodules, but checked out seperately)

          The only downside is the (in my opinion minnimal) performance hit for cding into each directory.

          Raphael Höser added a comment - You're currently doing something like "git blame <filepath>/<filename>". If you change this behavior to "cd <filepath> ; git blame <filename>" this would always work for all files correctly. (Also this would solve a problem if the warnings come from multiple repos, which are not submodules, but checked out seperately) The only downside is the (in my opinion minnimal) performance hit for cding into each directory.

          Ulli Hafner added a comment - - edited

          There is no filePath property available right now. Or how should I detect these modules?

          Ulli Hafner added a comment - - edited There is no filePath property available right now. Or how should I detect these modules?

          If I understand it correctly you somehow have the filepath in any shape or form which you pass to the GitBlamer.
          The Warnings-ng plugin shows this as "Folders" in the report. This information could be used.
          A also created an issue which was marked as duplicate where I saw the problem on the git blamer and not the warnings-ng side, because they also can resolve this problem by splitting the filename and the path and doing what I described.

          Raphael Höser added a comment - If I understand it correctly you somehow have the filepath in any shape or form which you pass to the GitBlamer. The Warnings-ng plugin shows this as "Folders" in the report. This information could be used. A also created an issue which was marked as duplicate where I saw the problem on the git blamer and not the warnings-ng side, because they also can resolve this problem by splitting the filename and the path and doing what I described.

          After digging around in the code from warnings-ng I can say that each issue in a report has a "getFolder()" method which returns the folder for the file of that issue.
          In my opinion this should be solved at an git-forensics-plugin level or even better in jgit (git implementation used by git-forensics-plugin).
          Sadly jgit is unrelated to this project and I didn't find an issue tracker for it.

          Raphael Höser added a comment - After digging around in the code from warnings-ng I can say that each issue in a report has a "getFolder()" method which returns the folder for the file of that issue. In my opinion this should be solved at an git-forensics-plugin level or even better in jgit (git implementation used by git-forensics-plugin). Sadly jgit is unrelated to this project and I didn't find an issue tracker for it.

          Ulli Hafner added a comment - - edited

          jgit is the low level API to access Git, it makes no sense to touch that API.

          In order to fix this issue only the Git Jenkins API (and the Git Forensics plugin) should be used (and the API of the warnings plugin).

          Ulli Hafner added a comment - - edited jgit is the low level API to access Git, it makes no sense to touch that API. In order to fix this issue only the Git Jenkins API (and the Git Forensics plugin) should be used (and the API of the warnings plugin).

            Unassigned Unassigned
            timsch Tim Schlüter
            Votes:
            5 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: