Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19354

Warnings plugin marks some doxygen warnings as new for every build

    • Icon: Bug Bug
    • Resolution: Incomplete
    • Icon: Minor Minor
    • warnings-plugin
    • None
    • I'm using doxygen v1.8.4, Jenkins v1.523, Warnings plugin v4.27 on A Windows 7 PC.

      Doxygen gives lots of warnings on one C source file (correct ones), of which two lines are oddly formatted:

      <xyz_DoA>:1: Warning: parameters of member xyz_DoA are not (all) documented
      <xyz_DoA>:1: Warning: return type of member xyz_DoA is not documented

      The warnings plugin will present these warnings as new warnings with each build.

          [JENKINS-19354] Warnings plugin marks some doxygen warnings as new for every build

          Ulli Hafner added a comment -

          Is xyz_DoA an actual file name? What is the original output that leads to the warning?

          Do all other warnings show up as old warnings?

          Ulli Hafner added a comment - Is xyz_DoA an actual file name? What is the original output that leads to the warning? Do all other warnings show up as old warnings?

          kd Jm added a comment -

          These two lines are the complete actual output concerning the code where the doxygen errors have been detected. Only the filename has been changed to something that silly name xyz_DoA, nothing else. These two lines are surrounded by normal looking 'old style' warnings for other lines. The strange format reported here is seen a few times on the entire project, not more than once per file; all other warnings show up using the regular format.

          kd Jm added a comment - These two lines are the complete actual output concerning the code where the doxygen errors have been detected. Only the filename has been changed to something that silly name xyz_DoA, nothing else. These two lines are surrounded by normal looking 'old style' warnings for other lines. The strange format reported here is seen a few times on the entire project, not more than once per file; all other warnings show up using the regular format.

          Ulli Hafner added a comment -

          Warnings are marked as new if the hash code changes from build to build. What is the XML serialization of these two warnings? Especially

           <contextHashCode>173167181</contextHashCode>

          ? Please have a look in the *warnings.xml file in your Jenkins jobs/job/builds/#number folder for this file. If the number is small, then the associated file could not be read.

          Is the path xyz_DoA a valid absolute path in the file system?

          Ulli Hafner added a comment - Warnings are marked as new if the hash code changes from build to build. What is the XML serialization of these two warnings? Especially <contextHashCode>173167181</contextHashCode> ? Please have a look in the *warnings.xml file in your Jenkins jobs/job/builds/#number folder for this file. If the number is small, then the associated file could not be read. Is the path xyz_DoA a valid absolute path in the file system?

          Ulli Hafner added a comment -

          Please answer the questions, otherwise I can't help...

          Ulli Hafner added a comment - Please answer the questions, otherwise I can't help...

          kd Jm added a comment -

          Sorry for the delay and thank you very much for your time.

          xys_DoA is not a path, it is the name of a function in our code. Sorry, I should have said that explicitly from the beginning.

          The hashcodes are indeed very small. e.g.
          <warning plugin="warnings@4.27">
          <message>parameters of member xyz_DoA are not (all) documented</message>
          <priority>NORMAL</priority>
          <key>479</key>
          <lineRanges>
          <range plugin="analysis-core@1.50">
          <start>0</start>
          <end>0</end>
          </range>
          </lineRanges>
          <primaryLineNumber>0</primaryLineNumber>
          <fileName>C:/jenkins/workspace/trunk-module-xyz</fileName>
          <moduleName></moduleName>
          <packageName>-</packageName>
          <category></category>
          <type>Doxygen</type>
          <contextHashCode>480</contextHashCode>
          <origin>warnings</origin>
          <pathName></pathName>
          <primaryColumnStart>0</primaryColumnStart>
          <primaryColumnEnd>0</primaryColumnEnd>
          </warning>

          The path listed under fileName is valid, but it is the path of the current working directory, not the location of the path to the source file where the error comes from. That should be C:/jenkins/workspace/trunk-module-xyz/src

          kd Jm added a comment - Sorry for the delay and thank you very much for your time. xys_DoA is not a path, it is the name of a function in our code. Sorry, I should have said that explicitly from the beginning. The hashcodes are indeed very small. e.g. <warning plugin="warnings@4.27"> <message>parameters of member xyz_DoA are not (all) documented</message> <priority>NORMAL</priority> <key>479</key> <lineRanges> <range plugin="analysis-core@1.50"> <start>0</start> <end>0</end> </range> </lineRanges> <primaryLineNumber>0</primaryLineNumber> <fileName>C:/jenkins/workspace/trunk-module-xyz</fileName> <moduleName></moduleName> <packageName>-</packageName> <category></category> <type>Doxygen</type> <contextHashCode>480</contextHashCode> <origin>warnings</origin> <pathName></pathName> <primaryColumnStart>0</primaryColumnStart> <primaryColumnEnd>0</primaryColumnEnd> </warning> The path listed under fileName is valid, but it is the path of the current working directory, not the location of the path to the source file where the error comes from. That should be C:/jenkins/workspace/trunk-module-xyz/src

          Ulli Hafner added a comment -

          I see. The detection of new warnings works only if the absolute path to the file of the warning can be determined. So the question that needs to be asked: why is the filename not set? What is the doxygen warning that is parsed? Is there no filename present?

          Ulli Hafner added a comment - I see. The detection of new warnings works only if the absolute path to the file of the warning can be determined. So the question that needs to be asked: why is the filename not set? What is the doxygen warning that is parsed? Is there no filename present?

          kd Jm added a comment -

          (Again sorry for all the delay.)

          The filename is indeed absent. You can validly argue that this is indeed an error of doxygen, but I hope that the plugin can be made robust against these doxygen oddities In any case, I intend to file a ticket on the doxygen site for this as well, but it currently remains on my long todo list.

          Again, the format given equals

          <xyz_DoA>:1: Warning: parameters of member xyz_DoA are not (all) documented
          <xyz_DoA>:1: Warning: return type of member xyz_DoA is not documented

          with xyz_DoA the name of the function.

          kd Jm added a comment - (Again sorry for all the delay.) The filename is indeed absent. You can validly argue that this is indeed an error of doxygen, but I hope that the plugin can be made robust against these doxygen oddities In any case, I intend to file a ticket on the doxygen site for this as well, but it currently remains on my long todo list. Again, the format given equals <xyz_DoA>:1: Warning: parameters of member xyz_DoA are not (all) documented <xyz_DoA>:1: Warning: return type of member xyz_DoA is not documented with xyz_DoA the name of the function.

          Ulli Hafner added a comment -

          Well, I don't see a way to compute new warnings if no file name is present. Do you have an idea and would like o fix it?

          Ulli Hafner added a comment - Well, I don't see a way to compute new warnings if no file name is present. Do you have an idea and would like o fix it?

            drulli Ulli Hafner
            kd_jm kd Jm
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: