-
Notifications
You must be signed in to change notification settings - Fork 99
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
composeUp using captureContainersOutputToFiles blocks gradle from completing #188
Comments
Could you please prepare a simple project that proves this behavior? Thanks! |
Hit the same problem. This is docker-compose using busybox to run single command "sleep 42" to test do:
The effect is:
Notice Forgot to mention 2 gradle versions tested:
and:
|
Thank you for your time you invested to reporting this issue! 👍 Unfortunately, I'm not able to reproduce the issue even with repository you prepared :( My output is this:
The only difference is that you are executing The thread to read containers output is executed as background thread so it shouldn't block process shutdown. My only idea is that you are using Gradle daemon - so could you please execute the same command with |
To fix this issue, we should forcibly close the daemon threads when Gradle execution finishes. Then using Gradle daemon, it's not the same as JVM shutdown. Unfortunately, I'm not aware of any Gradle API that would allow this. On other hand, the current behavior is required for some use-cases, like people start using I would like to add an option to change the behavior to support also your use-case anyway! If you know about a Gradle hook that would be executed after Gradle execution finishes, please let me know. |
Now, we are using a hook to interrupt the daemon threads after Gradle build finishes. It's released in |
Using composeUp and configuring a output log directory like:
captureContainersOutputToFiles = "..."
Prevents gradle from completing and gradle hangs with the following output:
BUILD SUCCESSFUL in 23s
1 actionable tasks: 1 executed
<-------------> 0% WAITING
I would expect the task to complete and the logs being written to the configured directory?
Or is it the gradle process that is piping the logs to the log directory so it must keep running?
(test using gradle 5.2.1)
The text was updated successfully, but these errors were encountered: