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

Testreport lacks of those test in which the hashcode of two different testsuite name coincide

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: xunit-plugin
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.89.2
      xUnit-Version: 1.102
      Jdk:1.8.0_151
      Os: Ubuntu 14.04.5 LTS
    • Similar Issues:

      Description

      The published testreport generated by xunit is wrong, if two testname files will result in the same hashcode.

      the class org.jenkinsci.plugins.xunit.service.XUnitConversionService uses the following logic, to create temporarily junit-xml files:

      File junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode() + JUNIT_FILE_POSTFIX);

      in my project, i have two Testclasses that produce the same hash-code.

      de.congstar.acceptancetests.aax.templates.komplett.EKOM02XTest
      de.congstar.acceptancetests.aax.templates.komplett.EKOM039Test

      the temp. generated junit-file for both source junit xml files was:
      generatedJUnitFiles/JUnit/TEST-747423851.xml

      that occurrs only on the jenkins server that runs on linux - on my local windows pc, the hashcollision does not occurr.

      as a result of this name-clash only the results of the last Testclass is reported to jenkins.

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          sascha_friederich Sascha Friederich created issue -
          sascha_friederich Sascha Friederich made changes -
          Field Original Value New Value
          Description The published testreport generated by xunit is wrong, if two testname files will result in the same hashcode.

          the class XUnitConversionService uses the following logic, to create temporarily junit-xml files:
          {code:java}
          File junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode() + JUNIT_FILE_POSTFIX);{code}
          in my project, i have two Testklasses that produce the same hash-code:

          de.congstar.acceptancetests.aax.templates.komplett.EKOM02XTest
           de.congstar.acceptancetests.aax.templates.komplett.EKOM039Test

          the generated junit-file was:
           generatedJUnitFiles/JUnit/TEST-747423851.xml

          as a result of this name-clash only the last Testclass is reported to jenkins.           		The published testreport generated by xunit is wrong, if two testname files will result in the same hashcode.

          the class XUnitConversionService uses the following logic, to create temporarily junit-xml files:
          {code:java}
          File junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode() + JUNIT_FILE_POSTFIX);{code}
          in my project, i have two Testclasses that produce the same hash-code.

          de.congstar.acceptancetests.aax.templates.komplett.EKOM02XTest
           de.congstar.acceptancetests.aax.templates.komplett.EKOM039Test

          the generated junit-file was:
           generatedJUnitFiles/JUnit/TEST-747423851.xml

          that occurrs only on the jenkins server that runs on linux - on my local windows pc, the hashcollision does not occurr.

          as a result of this name-clash only the results of the last Testclass is reported to jenkins.
          sascha_friederich Sascha Friederich made changes -
          Description The published testreport generated by xunit is wrong, if two testname files will result in the same hashcode.

          the class XUnitConversionService uses the following logic, to create temporarily junit-xml files:
          {code:java}
          File junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode() + JUNIT_FILE_POSTFIX);{code}
          in my project, i have two Testclasses that produce the same hash-code.

          de.congstar.acceptancetests.aax.templates.komplett.EKOM02XTest
           de.congstar.acceptancetests.aax.templates.komplett.EKOM039Test

          the generated junit-file was:
           generatedJUnitFiles/JUnit/TEST-747423851.xml

          that occurrs only on the jenkins server that runs on linux - on my local windows pc, the hashcollision does not occurr.

          as a result of this name-clash only the results of the last Testclass is reported to jenkins.           		The published testreport generated by xunit is wrong, if two testname files will result in the same hashcode.

          the class {{org.jenkinsci.plugins.xunit.service.XUnitConversionService}} uses the following logic, to create temporarily junit-xml files:
          {code:java}
          File junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode() + JUNIT_FILE_POSTFIX);{code}
          in my project, i have two Testclasses that produce the same hash-code.

          de.congstar.acceptancetests.aax.templates.komplett.EKOM02XTest
           de.congstar.acceptancetests.aax.templates.komplett.EKOM039Test

          the generated junit-file was:
           generatedJUnitFiles/JUnit/TEST-747423851.xml

          that occurrs only on the jenkins server that runs on linux - on my local windows pc, the hashcollision does not occurr.

          as a result of this name-clash only the results of the last Testclass is reported to jenkins.
          sascha_friederich Sascha Friederich made changes -
          Summary wrong testreport, if testnames result in same hashcode (because of temp. generated junit-files) wrong testreport, if testnames produce a hashcollision (because of temp. generated junit-files)
          sascha_friederich Sascha Friederich made changes -
          Description The published testreport generated by xunit is wrong, if two testname files will result in the same hashcode.

          the class {{org.jenkinsci.plugins.xunit.service.XUnitConversionService}} uses the following logic, to create temporarily junit-xml files:
          {code:java}
          File junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode() + JUNIT_FILE_POSTFIX);{code}
          in my project, i have two Testclasses that produce the same hash-code.

          de.congstar.acceptancetests.aax.templates.komplett.EKOM02XTest
           de.congstar.acceptancetests.aax.templates.komplett.EKOM039Test

          the generated junit-file was:
           generatedJUnitFiles/JUnit/TEST-747423851.xml

          that occurrs only on the jenkins server that runs on linux - on my local windows pc, the hashcollision does not occurr.

          as a result of this name-clash only the results of the last Testclass is reported to jenkins.           		The published testreport generated by xunit is wrong, if two testname files will result in the same hashcode.

          the class {{org.jenkinsci.plugins.xunit.service.XUnitConversionService}} uses the following logic, to create temporarily junit-xml files:
          {code:java}
          File junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode() + JUNIT_FILE_POSTFIX);{code}
          in my project, i have two Testclasses that produce the same hash-code.

          de.congstar.acceptancetests.aax.templates.komplett.EKOM02XTest
           de.congstar.acceptancetests.aax.templates.komplett.EKOM039Test

          the temp. generated junit-file for *both* source junit xml files was:
           generatedJUnitFiles/JUnit/TEST-747423851.xml

          that occurrs only on the jenkins server that runs on linux - on my local windows pc, the hashcollision does not occurr.

          as a result of this name-clash only the results of the last Testclass is reported to jenkins.
          sascha_friederich Sascha Friederich made changes -
          Assignee Andrew Bayer [ abayer ] Gregory Boissinot [ gbois ]
          Hide
          Permalink
          sascha_friederich Sascha Friederich added a comment -

          it took some amount of time, to track down the problem - could just anyone take a look at this issue?

          Show
          sascha_friederich Sascha Friederich added a comment - it took some amount of time, to track down the problem - could just anyone take a look at this issue?
          sascha_friederich Sascha Friederich made changes -
          Assignee Gregory Boissinot [ gbois ] Nikolas Falco [ nfalco79 ]
          nfalco Nikolas Falco made changes -
          Assignee Nikolas Falco [ nfalco79 ] Nikolas Falco [ nfalco ]
          nfalco Nikolas Falco made changes -
          Priority Major [ 3 ] Minor [ 4 ]
          Hide
          Permalink
          nfalco Nikolas Falco added a comment -

          Change priority since an easy workaround exists, rename one of test adding a character like _

          Are you running JUnit tests?

          Show
          nfalco Nikolas Falco added a comment - Change priority since an easy workaround exists, rename one of test adding a character like _ Are you running JUnit tests?
          Hide
          Permalink
          sascha_friederich Sascha Friederich added a comment - - edited

          Thanx for responding

          >Are you running JUnit tests?
          yes, we are running junit-tests.

          yes, renaming would be a workaround - but we have more than 1000 unit tests und unfortunately the hashcollsion is silent, so we dont know if it happens again (with other filenames)

          i think a simple check, if the generated target file name exists (and then choosing a different name) would be fix.

          File junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode() + JUNIT_FILE_POSTFIX);
while (junitTargetFile.exists()) {
    junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode()+"_"+ RandomStringUtils.randomAlphabetic(1) + JUNIT_FILE_POSTFIX);
}
...
//this method does not check, if the targetFile already exists.
inputMetric.convert(inputFile, junitTargetFile);

           

          Show
          sascha_friederich Sascha Friederich added a comment - - edited Thanx for responding >Are you running JUnit tests? yes, we are running junit-tests. yes, renaming would be a workaround - but we have more than 1000 unit tests und unfortunately the hashcollsion is silent, so we dont know if it happens again (with other filenames) i think a simple check, if the generated target file name exists (and then choosing a different name) would be fix. File junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode() + JUNIT_FILE_POSTFIX); while (junitTargetFile.exists()) { junitTargetFile = new File(parent, JUNIT_FILE_PREFIX + inputFile.hashCode()+ "_" + RandomStringUtils.randomAlphabetic(1) + JUNIT_FILE_POSTFIX); } ... // this method does not check, if the targetFile already exists. inputMetric.convert(inputFile, junitTargetFile);  
          Hide
          Permalink
          nfalco Nikolas Falco added a comment -

          Ok, I was interested to make a proper unit test (also if hascode of file object depends from absolute path so depends from O.S. and your jenkins workspace path).

          I'm already working on solution that is similar to yours but using UUID

          Show
          nfalco Nikolas Falco added a comment - Ok, I was interested to make a proper unit test (also if hascode of file object depends from absolute path so depends from O.S. and your jenkins workspace path). I'm already working on solution that is similar to yours but using UUID
          nfalco Nikolas Falco made changes -
          Summary wrong testreport, if testnames produce a hashcollision (because of temp. generated junit-files) Testreport lacks of those test in which the hashcode of two different testsuite name coincide
          Hide
          Permalink
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Nikolas Falco
          Path:
          src/main/java/org/jenkinsci/plugins/xunit/XUnitDefaultValues.java
          src/main/java/org/jenkinsci/plugins/xunit/service/XUnitConversionService.java
          src/main/java/org/jenkinsci/plugins/xunit/service/XUnitTransformer.java
          src/main/java/org/jenkinsci/plugins/xunit/types/CustomType.java
          src/test/java/org/jenkinsci/plugins/xunit/service/XUnitConversionServiceTest.java
          src/test/java/org/jenkinsci/plugins/xunit/service/XUnitTransformerTest.java
          http://jenkins-ci.org/commit/xunit-plugin/2885f4f57ceaa1e816db07ca414285935b83c783
          Log:
          JENKINS-48945 Testreport lacks of those test in which the hashcode of two different testsuite name coincide

          Use UUID instead the hashcode of the file to generate a unique converted test report.
          By default java provides a version 4 UUID that ensure be unique in the same JVM instance. Since there are no more JVM that works with the same workspace is enough. A version 1 UUID that use MAC address to ensure file is unique over Jenkins nodes is not needed since XUnitProcessor does not copy slave node report files back to master.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nikolas Falco Path: src/main/java/org/jenkinsci/plugins/xunit/XUnitDefaultValues.java src/main/java/org/jenkinsci/plugins/xunit/service/XUnitConversionService.java src/main/java/org/jenkinsci/plugins/xunit/service/XUnitTransformer.java src/main/java/org/jenkinsci/plugins/xunit/types/CustomType.java src/test/java/org/jenkinsci/plugins/xunit/service/XUnitConversionServiceTest.java src/test/java/org/jenkinsci/plugins/xunit/service/XUnitTransformerTest.java http://jenkins-ci.org/commit/xunit-plugin/2885f4f57ceaa1e816db07ca414285935b83c783 Log: JENKINS-48945 Testreport lacks of those test in which the hashcode of two different testsuite name coincide Use UUID instead the hashcode of the file to generate a unique converted test report. By default java provides a version 4 UUID that ensure be unique in the same JVM instance. Since there are no more JVM that works with the same workspace is enough. A version 1 UUID that use MAC address to ensure file is unique over Jenkins nodes is not needed since XUnitProcessor does not copy slave node report files back to master.
          nfalco Nikolas Falco made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          nfalco Nikolas Falco made changes -
          Resolution Fixed [ 1 ]
          Status In Progress [ 3 ] Resolved [ 5 ]
          Hide
          Permalink
          sascha_friederich Sascha Friederich added a comment -

          Thank You  for solving this issue so fast

          Show
          sascha_friederich Sascha Friederich added a comment - Thank You  for solving this issue so fast
          Hide
          Permalink
          sascha_friederich Sascha Friederich added a comment -

          is there a plan, when this bugfix will be released? (its not part of Version: 1.103)

          Show
          sascha_friederich Sascha Friederich added a comment - is there a plan, when this bugfix will be released? (its not part of Version: 1.103)

            People

            Assignee:
            nfalco Nikolas Falco
            Reporter:
            sascha_friederich Sascha Friederich
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: