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

Path should be stored relative to workspace

    Details

    • Similar Issues:
    • Released As:
      8.0.0

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            andne 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.

            Show
            andne 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.
            Hide
            drulli 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.

            Show
            drulli 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.
            Hide
            andne 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.

            Show
            andne 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.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: