I have a task that finalizes another task by creating an HTML report on its XML report.
tasks.withType(WhateverTask) { whatever ->
task "${whatever.name}HtmlReport" {
// ...
doLast {
// ...
}
}
whatever.finalizedBy "${whatever.name}HtmlReport"
}
Now if I execute the task whatever
it runs and generates its output file.
If whatever
found issues it also fails the build.
Either way whateverHtmlReport
is run after that and generates the HTML report.
But if I execute whateverHtmlReport
, then only the report transformation is done, but I'd like the XML report to be automatically be generated / updated first.
But if I add a dependsOn whatever
to the new task, the problem is, that the whateverHtmlReport
task is not run if the whatever
task did fail.
I didn't find a way to configure this properly, maybe except by introducing a third task that depends on both and is the one that should be called manually to generate the report, but this is merely a workaround.
Instead I'd like to ask for a way to add such a dependency to the task.
We've seen this kind of problem a few times. I see this as a problem with Gradle distinguishing between failures that prevent the task from producing any valid output and failures where the task produces usable output but fails due to some other 'expected' problem. For example, when a static analysis task fails to run the analysis tool (and so there's no results file) vs when the task successfully runs the analysis tool to produce the output file, but there were problems detected and so fails. In the first case, we shouldn't run the report task because the output it needs was not produced. In the second case, we can run the report task because the output file is fine. The build as a whole would still fail, but the report would be produced.
Another way to think about this is that the report task instead depends on the _outcome_ of the analysis task, rather than the task's output file, and so can always run regardless of whether the analysis task succeeds or fails. This combines aspects of a dependency and a finalizer.
@big-guy can you please take a look at this?
This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.
Most helpful comment
We've seen this kind of problem a few times. I see this as a problem with Gradle distinguishing between failures that prevent the task from producing any valid output and failures where the task produces usable output but fails due to some other 'expected' problem. For example, when a static analysis task fails to run the analysis tool (and so there's no results file) vs when the task successfully runs the analysis tool to produce the output file, but there were problems detected and so fails. In the first case, we shouldn't run the report task because the output it needs was not produced. In the second case, we can run the report task because the output file is fine. The build as a whole would still fail, but the report would be produced.
Another way to think about this is that the report task instead depends on the _outcome_ of the analysis task, rather than the task's output file, and so can always run regardless of whether the analysis task succeeds or fails. This combines aspects of a dependency and a finalizer.