• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • warnings-plugin
    • None
    • Windows 7

      Due to the way that my system is built, I've found I need to set up a custom Jenkins workspace but, in the build step, I'm launching a python script that moves to a specific location before starting to compile. Although I've got "resolve relative paths" checked it doesn't seem to be working properly; the files created in jobs/<myjob>/builds/<date>/workspace-files are all empty.

      I suspect this is caused by the odd way out code is built. The warnings tend to be of the form:

      ../../<a>/<b>/<c>/<d>/<e>.c:329: warning: empty body in an else-statement

      This is relative to the location where I run my build script, but that is somewhere down the path from the Jenkins workspace (e:\work\Jenkins).

      My suggestion is therefore to allow a root path to be used by the Compiler Warnings plugin when trying to resolve relative paths.

      If I were able to specify the root, let's say "E:\Work\Jenkins\<p1>\<p2>\<p3>", (where p1..p3 are replaced by my folder names) it should be easy for the warnings plugin to resolve "../../<a>/<b>/<c>/<d>/<e>.c" to "E:\Work\Jenkins\<p1>\<a>\<b>\<c>\<d>\<e>.c" correctly.

          [JENKINS-15801] Allow root of relative paths to be specified

          Joakim Plate added a comment -

          Have similar issue. Doing unit tests on submodules of a project with the following structure.

          file.c
          test/makefile

          Where makefile refere to parent directory objects. To start the build i issue something like:

          make -C test

          Joakim Plate added a comment - Have similar issue. Doing unit tests on submodules of a project with the following structure. file.c test/makefile Where makefile refere to parent directory objects. To start the build i issue something like: make -C test

          Joakim Plate added a comment - - edited

          <deleted> duplicate

          Joakim Plate added a comment - - edited <deleted> duplicate

          Ulli Hafner added a comment -

          @Joakim: shouldn't this work when you are using the new GCC parser that works in conjunction with make? (This still needs to be refactored, see JENKINS-14064).

          Ulli Hafner added a comment - @Joakim: shouldn't this work when you are using the new GCC parser that works in conjunction with make? (This still needs to be refactored, see JENKINS-14064 ).

          Joakim Plate added a comment -

          I would have thoughts so. But maybe it is because i execute the directory change (make -C) directly from the bash script instead of inside another make.

          Joakim Plate added a comment - I would have thoughts so. But maybe it is because i execute the directory change (make -C) directly from the bash script instead of inside another make.

          John McCabe added a comment -

          I had a look at https://issues.jenkins-ci.org/browse/JENKINS-14064 again after your comment @Ulli; I'd seen it before when I was searching for a possible solution. It's a similar issue but, as far as I can see, solving that would be a lot more difficult than this suggestion

          John McCabe added a comment - I had a look at https://issues.jenkins-ci.org/browse/JENKINS-14064 again after your comment @Ulli; I'd seen it before when I was searching for a possible solution. It's a similar issue but, as far as I can see, solving that would be a lot more difficult than this suggestion

          Ulli Hafner added a comment -

          Hopefully the fix for JENKINS-32150 is useful here, too.

          Ulli Hafner added a comment - Hopefully the fix for JENKINS-32150 is useful here, too.

            drulli Ulli Hafner
            jmccabe John McCabe
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: