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.

          Hide
          msiemczyk Maciek Siemczyk added a comment -

          Hi Gregory,

          If this is okay by you I could pick this one up and see if I can come up with a solution?

          Regards,
          Maciek

          Show
          msiemczyk Maciek Siemczyk added a comment - Hi Gregory, If this is okay by you I could pick this one up and see if I can come up with a solution? Regards, Maciek
          msiemczyk Maciek Siemczyk made changes -
          Assignee Gregory Boissinot [ gbois ] Maciek Siemczyk [ msiemczyk ]
          msiemczyk Maciek Siemczyk made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          msiemczyk Maciek Siemczyk added a comment -

          Hi Gregory,

          I've committed a fix and unit tests on my branch. Can you roll it in the new release?

          Thanks,
          Maciek

          Show
          msiemczyk Maciek Siemczyk added a comment - Hi Gregory, I've committed a fix and unit tests on my branch. Can you roll it in the new release? Thanks, Maciek
          msiemczyk Maciek Siemczyk made changes -
          Status In Progress [ 3 ] Open [ 1 ]
          Show
          msiemczyk Maciek Siemczyk added a comment - https://github.com/msiemczyk/xunit-plugin/commit/1b606180e27a8a1c237263f5667bc0c74adf6f7b
          Hide
          msiemczyk Maciek Siemczyk added a comment -

          Hi Gregory,

          It looks like the plugin is still failing when slave is remote. When I tried it on local master everything work. Do you have any idea why?

          Stack Trace:

          13:57:57 [xUnit] [INFO] - Starting to record.
          13:57:57 [xUnit] [INFO] - Processing CppUnit-1.12.1 (default)

          13:57:57 [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)'.
          13:57:57 ERROR: Publisher org.jenkinsci.plugins.xunit.XUnitPublisher aborted due to exception
          13:57:57 hudson.util.IOException2: remote file operation failed: e:\sandbox\Runtime_trunk at hudson.remoting.Channel@79fc4155:wtlswjs13
          13:57:57 at hudson.FilePath.act(FilePath.java:847)
          13:57:57 at hudson.FilePath.act(FilePath.java:824)
          13:57:57 at org.jenkinsci.plugins.xunit.XUnitPublisher.performTests(XUnitPublisher.java:189)
          13:57:57 at org.jenkinsci.plugins.xunit.XUnitPublisher.performXUnit(XUnitPublisher.java:118)
          13:57:57 at org.jenkinsci.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:93)
          13:57:57 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
          13:57:57 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:807)
          13:57:57 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:782)
          13:57:57 at hudson.model.Build$BuildExecution.post2(Build.java:183)
          13:57:57 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:729)
          13:57:57 at hudson.model.Run.execute(Run.java:1541)
          13:57:57 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          13:57:57 at hudson.model.ResourceController.execute(ResourceController.java:88)
          13:57:57 at hudson.model.Executor.run(Executor.java:236)
          13:57:57 Caused by: hudson.util.IOException2: There are some problems during the conversion into JUnit reports:
          13:57:57 at com.thalesgroup.hudson.plugins.xunit.service.XUnitTransformer.invoke(XUnitTransformer.java:174)
          13:57:57 at com.thalesgroup.hudson.plugins.xunit.service.XUnitTransformer.invoke(XUnitTransformer.java:38)
          13:57:57 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2308)
          13:57:57 at hudson.remoting.UserRequest.perform(UserRequest.java:118)
          13:57:57 at hudson.remoting.UserRequest.perform(UserRequest.java:48)
          13:57:57 at hudson.remoting.Request$2.run(Request.java:287)
          13:57:57 at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
          13:57:57 at java.util.concurrent.FutureTask.run(Unknown Source)
          13:57:57 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
          13:57:57 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          13:57:57 at hudson.remoting.Engine$1$1.run(Engine.java:60)
          13:57:57 at java.lang.Thread.run(Unknown Source)
          13:57:57 Caused by: java.lang.NullPointerException
          13:57:57 at com.thalesgroup.dtkit.metrics.model.InputMetricXSL.validateInputFile(InputMetricXSL.java:259)
          13:57:57 at com.thalesgroup.hudson.plugins.xunit.service.XUnitValidationService.validateInputFile(XUnitValidationService.java:80)
          13:57:57 at com.thalesgroup.hudson.plugins.xunit.service.XUnitTransformer.invoke(XUnitTransformer.java:130)
          13:57:57 ... 11 more
          13:57:57 Email was triggered for: Failure

          Show
          msiemczyk Maciek Siemczyk added a comment - Hi Gregory, It looks like the plugin is still failing when slave is remote. When I tried it on local master everything work. Do you have any idea why? Stack Trace: 13:57:57 [xUnit] [INFO] - Starting to record. 13:57:57 [xUnit] [INFO] - Processing CppUnit-1.12.1 (default) 13:57:57 [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)'. 13:57:57 ERROR: Publisher org.jenkinsci.plugins.xunit.XUnitPublisher aborted due to exception 13:57:57 hudson.util.IOException2: remote file operation failed: e:\sandbox\Runtime_trunk at hudson.remoting.Channel@79fc4155:wtlswjs13 13:57:57 at hudson.FilePath.act(FilePath.java:847) 13:57:57 at hudson.FilePath.act(FilePath.java:824) 13:57:57 at org.jenkinsci.plugins.xunit.XUnitPublisher.performTests(XUnitPublisher.java:189) 13:57:57 at org.jenkinsci.plugins.xunit.XUnitPublisher.performXUnit(XUnitPublisher.java:118) 13:57:57 at org.jenkinsci.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:93) 13:57:57 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) 13:57:57 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:807) 13:57:57 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:782) 13:57:57 at hudson.model.Build$BuildExecution.post2(Build.java:183) 13:57:57 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:729) 13:57:57 at hudson.model.Run.execute(Run.java:1541) 13:57:57 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) 13:57:57 at hudson.model.ResourceController.execute(ResourceController.java:88) 13:57:57 at hudson.model.Executor.run(Executor.java:236) 13:57:57 Caused by: hudson.util.IOException2: There are some problems during the conversion into JUnit reports: 13:57:57 at com.thalesgroup.hudson.plugins.xunit.service.XUnitTransformer.invoke(XUnitTransformer.java:174) 13:57:57 at com.thalesgroup.hudson.plugins.xunit.service.XUnitTransformer.invoke(XUnitTransformer.java:38) 13:57:57 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2308) 13:57:57 at hudson.remoting.UserRequest.perform(UserRequest.java:118) 13:57:57 at hudson.remoting.UserRequest.perform(UserRequest.java:48) 13:57:57 at hudson.remoting.Request$2.run(Request.java:287) 13:57:57 at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) 13:57:57 at java.util.concurrent.FutureTask.run(Unknown Source) 13:57:57 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 13:57:57 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 13:57:57 at hudson.remoting.Engine$1$1.run(Engine.java:60) 13:57:57 at java.lang.Thread.run(Unknown Source) 13:57:57 Caused by: java.lang.NullPointerException 13:57:57 at com.thalesgroup.dtkit.metrics.model.InputMetricXSL.validateInputFile(InputMetricXSL.java:259) 13:57:57 at com.thalesgroup.hudson.plugins.xunit.service.XUnitValidationService.validateInputFile(XUnitValidationService.java:80) 13:57:57 at com.thalesgroup.hudson.plugins.xunit.service.XUnitTransformer.invoke(XUnitTransformer.java:130) 13:57:57 ... 11 more 13:57:57 Email was triggered for: Failure
          msiemczyk Maciek Siemczyk made changes -
          Assignee Maciek Siemczyk [ msiemczyk ] Gregory Boissinot [ gbois ]
          Hide
          msiemczyk Maciek Siemczyk added a comment -

          We managed to make it work on one of the slaves. Apparently it was picking up old Xerces library from somewhere and the fix was to copy new library into endorsed Java directory. Any thoughts?

          Show
          msiemczyk Maciek Siemczyk added a comment - We managed to make it work on one of the slaves. Apparently it was picking up old Xerces library from somewhere and the fix was to copy new library into endorsed Java directory. Any thoughts?
          Hide
          msiemczyk Maciek Siemczyk added a comment - - edited

          I ended up disabling the two unit tests that are using Java 7 API.

          https://github.com/msiemczyk/xunit-plugin/commit/2f32af622600f39ddb59bdf317526c0afd7e6756

          Show
          msiemczyk Maciek Siemczyk added a comment - - edited I ended up disabling the two unit tests that are using Java 7 API. https://github.com/msiemczyk/xunit-plugin/commit/2f32af622600f39ddb59bdf317526c0afd7e6756
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: msiemczyk
          Path:
          .gitignore
          src/main/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationService.java
          src/test/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationServiceTest.java
          http://jenkins-ci.org/commit/xunit-plugin/1b606180e27a8a1c237263f5667bc0c74adf6f7b
          Log:
          Fix JENKINS-19877

          • Modified checkFileIsNotEmpty() method to use canonical file, which
            will resolve symbolic links, when possible.
          • Added 4 new unit tests to exercise the modified method. Two of the new
            unit tests are using new Java 7 IO API and JDK 7 or newer is required to
            compile them.
          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: msiemczyk Path: .gitignore src/main/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationService.java src/test/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationServiceTest.java http://jenkins-ci.org/commit/xunit-plugin/1b606180e27a8a1c237263f5667bc0c74adf6f7b Log: Fix JENKINS-19877 Modified checkFileIsNotEmpty() method to use canonical file, which will resolve symbolic links, when possible. Added 4 new unit tests to exercise the modified method. Two of the new unit tests are using new Java 7 IO API and JDK 7 or newer is required to compile them.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: msiemczyk
          Path:
          src/test/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationServiceTest.java
          http://jenkins-ci.org/commit/xunit-plugin/2f32af622600f39ddb59bdf317526c0afd7e6756
          Log:
          FIX JENKINS-19877

          Disabled two of the unit tests that are using Java 7 API.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: msiemczyk Path: src/test/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationServiceTest.java http://jenkins-ci.org/commit/xunit-plugin/2f32af622600f39ddb59bdf317526c0afd7e6756 Log: FIX JENKINS-19877 Disabled two of the unit tests that are using Java 7 API.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Gregory Boissinot
          Path:
          .gitignore
          src/main/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationService.java
          src/test/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationServiceTest.java
          http://jenkins-ci.org/commit/xunit-plugin/cd5dc2cc72ebb48a0a0278f82d9c11629e348f7c
          Log:
          Merge pull request #6 from msiemczyk/master

          Fix JENKINS-19877

          Compare: https://github.com/jenkinsci/xunit-plugin/compare/a54ae9f0e51c...cd5dc2cc72eb

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Gregory Boissinot Path: .gitignore src/main/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationService.java src/test/java/com/thalesgroup/hudson/plugins/xunit/service/XUnitValidationServiceTest.java http://jenkins-ci.org/commit/xunit-plugin/cd5dc2cc72ebb48a0a0278f82d9c11629e348f7c Log: Merge pull request #6 from msiemczyk/master Fix JENKINS-19877 Compare: https://github.com/jenkinsci/xunit-plugin/compare/a54ae9f0e51c...cd5dc2cc72eb
          gbois Gregory Boissinot made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Hide
          msiemczyk Maciek Siemczyk added a comment -

          Hi Gregory,

          We have installed 1.63 plugin on our main master and everything works great. Thanks for your help.

          Regards,
          Maciek

          Show
          msiemczyk Maciek Siemczyk added a comment - Hi Gregory, We have installed 1.63 plugin on our main master and everything works great. Thanks for your help. Regards, Maciek
          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: