Menu

#86 Merge task fails if one input file is corrupted

Eclipse3.3
closed-fixed
nobody
None
5
2013-05-27
2012-07-09
Ivan
No

I have a lot of coverage result files that come from many different sources (Junit, testNG, other)
So when I want to generate a report, a merge all the files into one with this ant call:

<merge destfile="${env.WORKSPACE}/coverage.es">
<fileset dir="${env.WORKSPACE}" includes="**/*.ec" />
</merge>

But some files can be corrupted (the test crashed or even isn't finished yet.
And then the whole task fails:
15:07:25 /tmp/jenkins_slave/workspace/DAILY_TESTS_ENDER/BuildUtil/advanced-tasks.xml:168: Unable to read /tmp/jenkins_slave/workspace/DAILY_TESTS_ENDER/jacoco.1340966180.ec

I would like to be able to say to the "merge" task that it should ignore corrupted/illegal/abnormal files instead of stopping.
IE:
Log a warning in MergeTask#loadSourceFiles() at line 116 instead of raising an exception.

Discussion

  • Marc R. Hoffmann

    This shouldn't happen, except two processes write to the same exec file at the same time.

    I'm a little bit sceptical about this request, because normally exec files are created within the build. If one of the exec files is broken, something went wrong during the build. I would at least see a new attribute 'failonerror' which is true by default.

     
  • Marc R. Hoffmann

    • labels: 1376401 -->
     
  • Ivan

    Ivan - 2012-07-09

    Well, in my case I also have "functional testing" that requires the whole software to be built not only one of the jars.
    Those tests are executed separately from the build part itself.
    And finally all the tests-results and coverage are merged together.

    As tests are run in parallel (to reduce the whole test plan duration) so I define a coverage-file per Software instance. (based on date in milisec)
    It is still possible but unlikely to have two tests having the same coverage file and corrupting each other output.

    ---

    Anyway, yes, something went wrong in the tests. (The Software crashed or became unresponsive)
    And in those cases I don"t want to have the whole coverage reporting step failed.
    I still would like to have some reports.

    ---

    You are right, the "failonerror" attribute would more correct than removing completely the error.

    ---

    Workaround:
    I managed something by doing a first step that merge one file at a time, catch any error and delete the file that caused it.
    Then I do the "normal" merge step.

    Sample:
    <target name="jacoco-check">
    <trycatch>
    <try>
    <merge destfile="${env.WORKSPACE}/coverage.tmp">
    <fileset file="${jacocoResource}" />
    </merge>
    </try>
    <catch>
    <echo> "Corrupted coverage file: ${jacocoResource}"</echo>
    <delete>
    <fileset file="${jacocoResource}" />
    </delete>
    </catch>
    </trycatch>
    </target>

    <target name="jacoco-report">
    <mkdir dir="${env.WORKSPACE}/tmp-classes" />
    <unzip dest="${env.WORKSPACE}/tmp-classes">
    <fileset dir="${Sismage.run.dir}/../jars/current">
    <include name="*.jar" />
    </fileset>
    </unzip>

    <echo> "Checking input files" </echo>
    <fileset id="jacoco.input.files" dir="${env.WORKSPACE}" includes="**/*.ec" />
    <foreach target="jacoco-check" parallel="true" inheritall="true" inheritrefs="true" param="jacocoResource" maxThreads="8">
    <fileset refid="jacoco.input.files" />
    </foreach>

    <merge destfile="${env.WORKSPACE}/coverage.es">
    <fileset dir="${env.WORKSPACE}" includes="**/*.ec" />
    </merge>

    <report>
    <executiondata>
    <file file="${env.WORKSPACE}/coverage.es" />
    </executiondata>

    <structure name="Sismage">
    <classfiles>
    <fileset dir="${env.WORKSPACE}/tmp-classes">
    <excludesfile name="./jacoco-exclude.txt" />
    </fileset>

    </classfiles>
    </structure>

    <html destdir="${env.WORKSPACE}/coverage" />

    </report>
    <delete dir="${env.WORKSPACE}/tmp-classes" />
    </target>

     
  • Marc R. Hoffmann

    • status: open --> closed-fixed
    • Group: --> Eclipse3.3