We have an Exec-like task, which runs a tool that produces output to STDOUT. We want to run this task from a different task (let’s call it the Check task), eat up the tool’s STDOUT and to do some checks on it. Is there a way to do this?
We tried various things, but the only thing that we managed to get working is to define the Check task as a sub-class of the Exec-like task and instantiate it “in parallel”, instead of chaining the two task (i.e. Check depends on Exec).
Would there be a way to do this without modifying the original exec-like task, though? Assuming, for example, that the task comes from some plugin that I don’t have control over.
Also, I’d like to be able to toggle this behavior. When the exec-like task runs, it’s fine that it prints to STDOUT, because users want to see this output. This task runs an example that shows how to use code from the project and the output of the task is interesting for whoever uses it. The second task should just run this task and check that its output is correct. In such a case, the user is not interested in the concrete output of the example task, particularly not when the check is successful.
If it is an “exec-like” task I have no idea whether you can configure it accordingly.
An Exec task I think you could configure accordingly even if it is not yours.
Maybe you should not make the check task a task but a test?
Or maybe you can use the tooling API in the check task to execute the exec-like task as a new Gradle build and then there capture the build output to check it.
I think you could set the standardOutput to a byte array output stream and then echo it to System.out and also saving to a file that you add as output file to the task. Much like tee on a Linux command line.