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

Existing issues are marked as new when only line number changes

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • warnings-ng-plugin
    • None

      When using a reference job , when number of a line with a warning changes ( without content change ) then a new issue is opened.

       

      In attached image,

      • the new issue xml in on the left
      • outstanding issues xml is on the right

       

      The same fingerprint is seen.

          [JENKINS-62308] Existing issues are marked as new when only line number changes

          Ulli Hafner added a comment -

          Ulli Hafner added a comment - See discussion in https://gitter.im/jenkinsci/warnings-plugin?at=5ebe8f64863019312a5f8ebb

          Ava added a comment -

          Hello, I am seeing this issue too. If someone adds a comment at the beginning of a file then all subsequent warnings in that file will be marked as new. This fails our quality gate as we don't allow any 'new' issues. Can we remove the line number from the calculation or find a way to see that although the line number changed the code did not and make the issue as outstanding?

          Ava added a comment - Hello, I am seeing this issue too. If someone adds a comment at the beginning of a file then all subsequent warnings in that file will be marked as new. This fails our quality gate as we don't allow any 'new' issues. Can we remove the line number from the calculation or find a way to see that although the line number changed the code did not and make the issue as outstanding?

          Ulli Hafner added a comment -

          Actually warnings are not considered as new, if the source code below and after the warning does not change. It seems that this approach does not work in your setup? Are the source code files correctly resolved?

          Ulli Hafner added a comment - Actually warnings are not considered as new, if the source code below and after the warning does not change. It seems that this approach does not work in your setup? Are the source code files correctly resolved?

          Ava added a comment -

          Actually, that might be our issue. We seem to get this issue for all our files 

          Can't create fingerprints for some files:

          • '/home/jenkins/jenkins_slave/workspace/control.cpp' file not found
          • '/home/jenkins/jenkins_slave/workspace/video_overlay.cpp' file not found

           
          Is there a some setting or place to manage creating the fingerprints for our source files? For some context, we are using a custom GCC warnings parse and Warnings Next Generation version 9.23.1. 
           
          Thanks! 
           

          Ava added a comment - Actually, that might be our issue. We seem to get this issue for all our files  Can't create fingerprints for some files: '/home/jenkins/jenkins_slave/workspace/control.cpp' file not found '/home/jenkins/jenkins_slave/workspace/video_overlay.cpp' file not found   Is there a some setting or place to manage creating the fingerprints for our source files? For some context, we are using a custom GCC warnings parse and Warnings Next Generation version 9.23.1.    Thanks!   

          Ulli Hafner added a comment -

          There are no settings to alter. It seems that your parser or log output does not contain the correct path, as the source files are read from the top level folder of your workspace.

          Ulli Hafner added a comment - There are no settings to alter. It seems that your parser or log output does not contain the correct path, as the source files are read from the top level folder of your workspace.

          Ava added a comment - - edited

          Interesting.. is the fingerprint method used in this plugin the same as the one documented here https://www.jenkins.io/doc/book/using/fingerprints/ ?

          I am running into the issue where I am using Declarative Jenkins pipelines so I do not have the post-build actions to easily record fingerprints. Does the Warnings NG plugin require that I record fingerprints for all files? Seems that my Jenkins is not recording the fingerprints as when I do "Check File Fingerpint" with an artifact I get 

          No matching record found
          
          The fingerprint # did not match any of the recorded data. 
          1. Perhaps the file was not created under Jenkins. Maybe it’s a version that someone built locally on his/her own machine.
          2. Perhaps the projects are not set up correctly and not recording fingerprints. Check the project setting.

          Ava added a comment - - edited Interesting.. is the fingerprint method used in this plugin the same as the one documented here https://www.jenkins.io/doc/book/using/fingerprints/ ? I am running into the issue where I am using Declarative Jenkins pipelines so I do not have the post-build actions to easily record fingerprints. Does the Warnings NG plugin require that I record fingerprints for all files? Seems that my Jenkins is not recording the fingerprints as when I do "Check File Fingerpint" with an artifact I get  No matching record found The fingerprint # did not match any of the recorded data. 1. Perhaps the file was not created under Jenkins. Maybe it’s a version that someone built locally on his/her own machine. 2. Perhaps the projects are not set up correctly and not recording fingerprints. Check the project setting.

          Ulli Hafner added a comment -

          No, these fingerprints have nothing in common (just the name).

          Ulli Hafner added a comment - No, these fingerprints have nothing in common (just the name).

          Ava added a comment -

          Ah thank you for the clarification.

          I think the problem is that the plugin is looking in the $WORKSPACE/build folder for the source files when they are actually in $WORKSPACE/src and $WORKSPACE/include. I have tried setting sourceDirectory: "${WORKSPACE}/src" but I am getting

          'Removing source directory '${WORKSPACE}/src' - it has not been approved in Jenkins' global configuration.'

           

          Adding it to the Warnings Next Generation Plugin Global Settings - Source Code Directories Absolute Path does not seem to help either. It seems like that path is for outside of the workspace but I would just like to point the plugin to an alternate folder in the workspace.

          Ava added a comment - Ah thank you for the clarification. I think the problem is that the plugin is looking in the $WORKSPACE/build folder for the source files when they are actually in $WORKSPACE/src and $WORKSPACE/include. I have tried setting sourceDirectory: "${WORKSPACE}/src" but I am getting 'Removing source directory '${WORKSPACE}/src' - it has not been approved in Jenkins' global configuration.'   Adding it to the Warnings Next Generation Plugin Global Settings - Source Code Directories Absolute Path does not seem to help either. It seems like that path is for outside of the workspace but I would just like to point the plugin to an alternate folder in the workspace.

          Ava added a comment -

          I think I found my problem. It was related to this ticket https://issues.jenkins.io/browse/JENKINS-70443

           

          Thank you !

          Ava added a comment - I think I found my problem. It was related to this ticket https://issues.jenkins.io/browse/JENKINS-70443   Thank you !

          Ulli Hafner added a comment -

          You can either use a relative path (to the workspace) or an absolute path. Environment variables are not expended.

          Ulli Hafner added a comment - You can either use a relative path (to the workspace) or an absolute path. Environment variables are not expended.

            drulli Ulli Hafner
            akarapatis Athanasios Karapatis
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: