• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • analysis-model
    • None
    • 8.0.0

      Currently, all paths are resolved to an absolute path. It would rather make sense to store a relative path only in the issue and link to the base folder in a report.

          [JENKINS-57556] Path should be stored relative to workspace

          Andy Neebel added a comment -

          I think this is also needed in order to properly handle scans of parallel nodes. Different build nodes aren't guaranteed to have the same root folder, or if a single node is running multiple parallel blocks at once the workspace path contains @2, @3, etc... This results in the same warning getting counted either once if workspace paths match or multiple times if the workspace path does not match. We compile C++ for multiple targets in a single job, or to also run unit tests with coverage enabled, so parallel and the same compiler running on the same file is helpful and common. Storing only the relative path should mean that the same warning from different passes on the same file only gets counted once regardless of the number of times it was output.

          Andy Neebel added a comment - I think this is also needed in order to properly handle scans of parallel nodes. Different build nodes aren't guaranteed to have the same root folder, or if a single node is running multiple parallel blocks at once the workspace path contains @2, @3, etc... This results in the same warning getting counted either once if workspace paths match or multiple times if the workspace path does not match. We compile C++ for multiple targets in a single job, or to also run unit tests with coverage enabled, so parallel and the same compiler running on the same file is helpful and common. Storing only the relative path should mean that the same warning from different passes on the same file only gets counted once regardless of the number of times it was output.

          Ulli Hafner added a comment -

          Yes, it would also help to reduce the number of false positives for new warnings (due to a changed root folder).

          On the other side, I am not sure how this would work with aggregated reports. Currently one can combine several reports into a single one that will be reported in the UI. Should this be possible only if the root paths match? Otherwise the root path would not be unique anymore.

          Ulli Hafner added a comment - Yes, it would also help to reduce the number of false positives for new warnings (due to a changed root folder). On the other side, I am not sure how this would work with aggregated reports. Currently one can combine several reports into a single one that will be reported in the UI. Should this be possible only if the root paths match? Otherwise the root path would not be unique anymore.

          Andy Neebel added a comment -

          I guess either way would function, but I think I'd rather not have that limitation. My current use case is to run my code through multiple compilers for multiple targets (a couple are GCC based, others are different). I want to merge all of those results into a single report of Compiler Warnings. As long as my number doesn't change, I'm not as worried about what the number is. However, when I'm also running my Windows target twice, once for release and once to get test coverage metrics, I can potentially get duplicate warnings if the root path is part of the check. If the warning otherwise matches (and maybe if the parser matches?, that may already be in the check), identical paths relative to the workspace root (which may not match the reported path from the compiler I suppose) should be able to be treated as one warning since in theory the same change should fix it for however many occurrences exist.

          Andy Neebel added a comment - I guess either way would function, but I think I'd rather not have that limitation. My current use case is to run my code through multiple compilers for multiple targets (a couple are GCC based, others are different). I want to merge all of those results into a single report of Compiler Warnings. As long as my number doesn't change, I'm not as worried about what the number is. However, when I'm also running my Windows target twice, once for release and once to get test coverage metrics, I can potentially get duplicate warnings if the root path is part of the check. If the warning otherwise matches (and maybe if the parser matches?, that may already be in the check), identical paths relative to the workspace root (which may not match the reported path from the compiler I suppose) should be able to be treated as one warning since in theory the same change should fix it for however many occurrences exist.

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

              Created:
              Updated:
              Resolved: