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

xUnit does not support symbolic link for input files

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: xunit-plugin
    • Labels:
      None
    • Environment:
      plugin version: 1.48
      Jenkins v1.487
      Windows 2008 R2
    • Similar Issues:

      Description

      Recently, we switched our build system to use symbolic links instead of copying files around and turns out that the xUnit plugin does not work with them. The file is found, but plugin thinks that the file is empty.

      14:02:31 [xUnit] [INFO] - [CppUnit-1.12.1 (default)] - 1 test report file(s) were found with the pattern '*/exports/unittest//UnitTestResults.xml' relative to 'e:\sandbox\Runtime_trunk' for the testing framework 'CppUnit-1.12.1 (default)'.
      14:02:31 [xUnit] [ERROR] - The result file 'e:\sandbox\Runtime_trunk\outputs\exports\unittest\win32\UnitTestResults.xml' for the metric 'CppUnit' is empty. The result file has been skipped.

      I've looked into the code that causes failure; a call to:

      public boolean checkFileIsNotEmpty(File inputFile) {
      return inputFile.length() != 0;
      }

      The native symbolic links support was added to Java 7. I'm not sure if simply rebuilding plugin with JDK 7 will return non zero file size for symbolic links (Windows itself shows file size as zero) or is that even feasible as it forces Java 7. Or maybe the code needs to check first if the file is symbolic link and treat it differently.

      I guess another possible solution (assuming that we can read the file content in using old file class) would be to load the file content and check if that is non zero.

        Attachments

          Activity

          msiemczyk Maciek Siemczyk created issue -
          msiemczyk Maciek Siemczyk made changes -
          Field Original Value New Value
          Description Recently, we switched our build system to use symbolic links instead of copying files around and turns out that the xUnit plugin does not work with them. The file is found, but plugin thinks that the file is empty.

          14:02:31 [xUnit] [INFO] - [CppUnit-1.12.1 (default)] - 1 test report file(s) were found with the pattern '**/exports/unittest/*/UnitTestResults.xml' relative to 'e:\sandbox\Runtime_trunk' for the testing framework 'CppUnit-1.12.1 (default)'.
          14:02:31 [xUnit] [ERROR] - The result file 'e:\sandbox\Runtime_trunk\outputs\exports\unittest\win32\UnitTestResults.xml' for the metric 'CppUnit' is empty. The result file has been skipped.

          I've looked into the code that causes failure; a call to:

          public boolean checkFileIsNotEmpty(File inputFile) {
                  return inputFile.length() != 0;
          }

          The file class is the old implementation: import java.io.File;

          The native symbolic links support was added to Java 7 and there is a new File class in java.nio namespace. I'm not sure if simply changing class to the new one will return non zero file size for symbolic links (Windows itself shows file size as zero) or is that even feasible as it forces Java 7.

          I guess another possible solution (assuming that we can read the file content in using old file class) would be to load the file content and check if that is non zero.

          Recently, we switched our build system to use symbolic links instead of copying files around and turns out that the xUnit plugin does not work with them. The file is found, but plugin thinks that the file is empty.

          14:02:31 [xUnit] [INFO] - [CppUnit-1.12.1 (default)] - 1 test report file(s) were found with the pattern '**/exports/unittest/*/UnitTestResults.xml' relative to 'e:\sandbox\Runtime_trunk' for the testing framework 'CppUnit-1.12.1 (default)'.
          14:02:31 [xUnit] [ERROR] - The result file 'e:\sandbox\Runtime_trunk\outputs\exports\unittest\win32\UnitTestResults.xml' for the metric 'CppUnit' is empty. The result file has been skipped.

          I've looked into the code that causes failure; a call to:

          public boolean checkFileIsNotEmpty(File inputFile) {
                  return inputFile.length() != 0;
          }

          The file class is the old implementation: import java.io.File;

          The native symbolic links support was added to Java 7. I'm not sure if simply rebuilding plugin with JDK 7 will return non zero file size for symbolic links (Windows itself shows file size as zero) or is that even feasible as it forces Java 7. Or maybe the code needs to check first if the file is symbolic link and treat it differently.

          I guess another possible solution (assuming that we can read the file content in using old file class) would be to load the file content and check if that is non zero.

          msiemczyk Maciek Siemczyk made changes -
          Description Recently, we switched our build system to use symbolic links instead of copying files around and turns out that the xUnit plugin does not work with them. The file is found, but plugin thinks that the file is empty.

          14:02:31 [xUnit] [INFO] - [CppUnit-1.12.1 (default)] - 1 test report file(s) were found with the pattern '**/exports/unittest/*/UnitTestResults.xml' relative to 'e:\sandbox\Runtime_trunk' for the testing framework 'CppUnit-1.12.1 (default)'.
          14:02:31 [xUnit] [ERROR] - The result file 'e:\sandbox\Runtime_trunk\outputs\exports\unittest\win32\UnitTestResults.xml' for the metric 'CppUnit' is empty. The result file has been skipped.

          I've looked into the code that causes failure; a call to:

          public boolean checkFileIsNotEmpty(File inputFile) {
                  return inputFile.length() != 0;
          }

          The file class is the old implementation: import java.io.File;

          The native symbolic links support was added to Java 7. I'm not sure if simply rebuilding plugin with JDK 7 will return non zero file size for symbolic links (Windows itself shows file size as zero) or is that even feasible as it forces Java 7. Or maybe the code needs to check first if the file is symbolic link and treat it differently.

          I guess another possible solution (assuming that we can read the file content in using old file class) would be to load the file content and check if that is non zero.

          Recently, we switched our build system to use symbolic links instead of copying files around and turns out that the xUnit plugin does not work with them. The file is found, but plugin thinks that the file is empty.

          14:02:31 [xUnit] [INFO] - [CppUnit-1.12.1 (default)] - 1 test report file(s) were found with the pattern '**/exports/unittest/*/UnitTestResults.xml' relative to 'e:\sandbox\Runtime_trunk' for the testing framework 'CppUnit-1.12.1 (default)'.
          14:02:31 [xUnit] [ERROR] - The result file 'e:\sandbox\Runtime_trunk\outputs\exports\unittest\win32\UnitTestResults.xml' for the metric 'CppUnit' is empty. The result file has been skipped.

          I've looked into the code that causes failure; a call to:

          public boolean checkFileIsNotEmpty(File inputFile) {
                  return inputFile.length() != 0;
          }

          The native symbolic links support was added to Java 7. I'm not sure if simply rebuilding plugin with JDK 7 will return non zero file size for symbolic links (Windows itself shows file size as zero) or is that even feasible as it forces Java 7. Or maybe the code needs to check first if the file is symbolic link and treat it differently.

          I guess another possible solution (assuming that we can read the file content in using old file class) would be to load the file content and check if that is non zero.

          msiemczyk Maciek Siemczyk made changes -
          Assignee Gregory Boissinot [ gbois ] Maciek Siemczyk [ msiemczyk ]
          msiemczyk Maciek Siemczyk made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          msiemczyk Maciek Siemczyk made changes -
          Status In Progress [ 3 ] Open [ 1 ]
          msiemczyk Maciek Siemczyk made changes -
          Assignee Maciek Siemczyk [ msiemczyk ] Gregory Boissinot [ gbois ]
          gbois Gregory Boissinot made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          msiemczyk Maciek Siemczyk made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 151398 ] JNJira + In-Review [ 207004 ]

            People

            Assignee:
            gbois Gregory Boissinot
            Reporter:
            msiemczyk Maciek Siemczyk
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: