Shouldn't call gradle twice in a build
I often watch TV series/movies during my spare time. But, occasionally, I work with my pet projects. Recently I have added tests and fixed minor bugs for an existing project using CircleCI and coveralls.io for continuous integration and code coverage collecting.
The frustrating thing is that coveralls.io also collects coverage for builds which has failed tests while I want to track only the builds of which all tests pass. So, the record of coveralls contains more items than the number of my success builds and it makes me really disturbed.
I tried to figure out the way to achieve what happened. And here is the explanation:
- test for running the unit/integration tests.
- jacocoTestReport for generating test reports file (xml for machine-reading and html for human-reading), this task must be carried out after the test task
- coveralls for collecting the reports generated by jacocoTestReport, so this task must be performed last.
test {
//...... my test jobs
finalizedBy jacocoTestReport
}
In circle.yml file, I run test and coveralls in 2 commands:
test:
override:
- ./gradlew test
- ./gradlew coveralls
In this solution, the keyword finalizedBy makes sure that jacocoTestReport task will be called to perform even though the test task fails, and the reports will be generated.
After that, the coveralls task will separatedly called. And because there are existing reports, the task will collect them and send to the service. That why coveralls.io records my unsuccessful builds.
task.coveralls {
dependsOn test
}
By that time I have to run only coveralls task in circle.yml:
test:
override:
- ./gradlew coveralls
The build process will first execute the test task and generate reports.
I also think that when a build fails, the coverall will not executed, so the reports don't have to appear, and I intend to skip that part, but I re-think, the report will still be useful when I want to know the reason my build fails.
Tonight is Christmas Eve, if you are reading this, I wish you a merry Christmas.
The frustrating thing is that coveralls.io also collects coverage for builds which has failed tests while I want to track only the builds of which all tests pass. So, the record of coveralls contains more items than the number of my success builds and it makes me really disturbed.
I tried to figure out the way to achieve what happened. And here is the explanation:
1/ The flow
I use Gradle build system to automatically build, test and collect code coverage. Each of my builds contains 3 main Gradle tasks:- test for running the unit/integration tests.
- jacocoTestReport for generating test reports file (xml for machine-reading and html for human-reading), this task must be carried out after the test task
- coveralls for collecting the reports generated by jacocoTestReport, so this task must be performed last.
2/ My previous solution (bad)
In build.gradle file, I modify the test task and make it finalized by jacocoTestReport:test {
//...... my test jobs
finalizedBy jacocoTestReport
}
In circle.yml file, I run test and coveralls in 2 commands:
test:
override:
- ./gradlew test
- ./gradlew coveralls
In this solution, the keyword finalizedBy makes sure that jacocoTestReport task will be called to perform even though the test task fails, and the reports will be generated.
After that, the coveralls task will separatedly called. And because there are existing reports, the task will collect them and send to the service. That why coveralls.io records my unsuccessful builds.
3/ My current solution
I realize that the build process shouldn't perform coveralls task when the test task fails. To do so, I add a dependency from coveralls to test in build.gradle:task.coveralls {
dependsOn test
}
By that time I have to run only coveralls task in circle.yml:
test:
override:
- ./gradlew coveralls
The build process will first execute the test task and generate reports.
I also think that when a build fails, the coverall will not executed, so the reports don't have to appear, and I intend to skip that part, but I re-think, the report will still be useful when I want to know the reason my build fails.
Tonight is Christmas Eve, if you are reading this, I wish you a merry Christmas.
Comments
Post a Comment