New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Execute tests and kover separately (Gradle-plugin) #565
Comments
Hi, |
Build cache is not a solution in this case, as the tests still run twice, which may extend the pipeline for several hours. The pipeline always has one step for the jUnit tests, a second for the Cucumber tests and there may also be various E2E tests in Cucumber. I would like to be able to control when which tests are called. It is also a massive problem that the tasks are automatically attached to the build task. A simple configuration of which tasks should be attached to would be much better. If these tasks are then executed, the agent should also be attached, but should not affect the other dependencies. |
If using build cache and no sources changed tests shouldn't execute again. |
In the Kover Gradle Plugin, you can build a report only on completed tests or taken from the cache. Building the report later in a separate build requires manual configuration and use, for example, Kover CLI. For a custom pipeline, you may use the Kover instrumentation agent and independently instrument the necessary tasks, collect binary reports from different builds and generate human-readable reports on them by Kover CLI. |
Also, in Kover Gradle Plugin you can disable running of some test tasks by their name.
In
But in this case, you cannot generate a readable report (XML or HTML), because you do not run the second task. |
In our build pipeline, jUnit tests and Cucumber tests are separated.
The coverage report should basically be created afterwards.
Is there a way to configure the Gradle plugin so that it only creates the report but does not run the tests again?
I could do this via CLI with
gradle koverXmlReport -x test -x cucumber
.However, we also use a build library that controls the tasks. If I now have to add all the excludes per project, this is always an unnecessary configuration effort that can quickly go wrong.
Thanks!
The text was updated successfully, but these errors were encountered: