Skip to content

Releases: avast/gradle-docker-compose-plugin

projectNamePrefix option introduces

11 May 15:37
Compare
Choose a tag to compare

As requested in #231, it allows executing the same Gradle project concurrently.

Exposed port reloaded after TCP check failure

11 May 14:42
Compare
Choose a tag to compare
0.10.12

fix: forwarded port reloaded after failing check Fixes #229

Problems when a service is scaled to 0 instances solved

08 May 21:22
Compare
Choose a tag to compare
0.10.11

Fixed ServiceInfo when no service instances exist

checkContainersRunning option added

08 Apr 13:52
Compare
Choose a tag to compare

When this option is active (it is by default) then also checks if the container is running, when waiting for an open port or healthy state. So this is a fail-fast feature because it is obvious that the container will not open an port if it even doesn't run.

Table with exposed ports printed after composeUp finish

14 Feb 14:36
Compare
Choose a tag to compare
table with exposed ports printed after composeUp finish

Fixes #186

Correct handling of InterruptedExceptions in Gradle before 5.0

14 Feb 12:09
Compare
Choose a tag to compare

This release fixes just cosmetics - any error message shouldn't be printed when finishing the build.

More information stored to the cache

14 Dec 21:10
Compare
Choose a tag to compare

The containers are now restarted also when docker-compose.yml has been changed.

Exceptions after successful build removed from the log

13 Dec 21:19
Compare
Choose a tag to compare
0.10.6

fix: InterruptedException ignored when a daemon thread is interrupted…

Containers stopped correctly after failure with starting

10 Dec 21:16
Compare
Choose a tag to compare

This fixes an issue with calling docker-compose down if the previous docker-compose up failed.

isRequiredBy fixed for TaskProvider and classes task

19 Nov 10:36
Compare
Choose a tag to compare

There is an optimization that ensures that classes task is executed before composeUp (so it's active for Java projects only). There was an issue because TaskProvider.configure() was called from another configure method, and we didn't know that this is not allowed.

This is fixed and also this use-case is now also covered by tests.