gradle-docker-compose-plugin
gradle-docker-compose-plugin copied to clipboard
workaround for docker not found error
I think there's something wonky with how the docker command is resolved. I commented about a simple workaround a few weeks ago on this on one of the closed tickets: https://github.com/avast/gradle-docker-compose-plugin/issues/406#issuecomment-1872674429
But after fixing this again on another project, I think it would be nice to just integrate the fix in the plugin or at least document the workaround somewhere.
In short, on Java 21 (with sdkman), docker for desktop, and mac the plugin is no longer able to resolve the docker command from gradle.
Here's the work around:
listOf("/usr/bin/docker","/usr/local/bin/docker").firstOrNull {
File(it).exists()
}?.let { docker ->
// works around an issue where the docker
// command is not found
// falls back to the default, which may work on
// some platforms
dockerExecutable.set(docker)
}
What this does is it tries to lookup the docker command in a few standard locations where it would normally be found before falling back to the existing behavior of trying to do magic via the PATH variable. Somehow it skips /usr/local/bin/docker, which is where I definitely have it and which is definitely on my PATH. It worked in Java 17 and somehow after switching to Java 21 (via sdkman, this may be a factor) it doesn't.
I had the same issue, but only recently, and only when I was executing the gradle task from IntelliJ IDEA Ultimate. It was working from the command line without any issues.
I was about to share my specs (jdk, gradle, intellij versions, etc), but while doing so I did some changes and it got fixed.
Notably:
- I reset IntelliJ's SDK settings (removed JDK, added the same again). It's Azul Zulu 21, in case it's relevant for anyone.
- Thinking about it, it's not actually the same - the path is different. It was added as the path where SDKMAN put it. Now I added it with the path in the
current
folder. Not sure if it's relevant, but given howJAVA_HOME
points to the current folder as well, thought I'd share it
- Thinking about it, it's not actually the same - the path is different. It was added as the path where SDKMAN put it. Now I added it with the path in the
- I reset the Gradle settings so that it uses the same SDK as I just set (it was set to that earlier as well, not sure what changed..)
After doing the above two, I could now run the gradle task from IntelliJ as well
I've had the issue both on the command line and in the IDE. This does not seem to relate to intellij settings at all for me at least. But instead of a maybe this will work or that will work, we should just make this less flaky? It's clearly failing to resolve things that are clearly there and listed on a PATH.
This gradle issue seems related: https://github.com/gradle/gradle/issues/26453
Same here, but only with IntelliJ
A variant of the original workaround that assumes the /usr/local/bin
location on MacOS:
import org.gradle.nativeplatform.platform.internal.DefaultNativePlatform
...
dockerCompose {
if (DefaultNativePlatform.currentOperatingSystem.macOsX) {
executable = '/usr/local/bin/docker-compose'
dockerExecutable = '/usr/local/bin/docker'
}
}
Same issue here.
It seems related to: https://github.com/gradle/gradle/issues/10483
This happened to me when I had my project set to Java 21 (via a .sdkmanrc
file) and my build.gradle had sourceCompatibility
and targetCompatibility
set to 21, but my default SDK as set within SDKman was Java 17.
Once I ran sdk default java 21.0.2-tem
, it worked correctly.
My working work around version:
// Works around an issue where the docker command is not found.
// Falls back to the default, which may work on some platforms.
// https://github.com/avast/gradle-docker-compose-plugin/issues/435
// https://github.com/gradle/gradle/issues/10483
if (DefaultNativePlatform.getCurrentOperatingSystem().isMacOsX) {
listOf("/usr/bin/docker-compose", "/usr/local/bin/docker-compose").firstOrNull {
File(it).exists()
}?.let { docker ->
executable.set(docker)
}
listOf("/usr/bin/docker", "/usr/local/bin/docker").firstOrNull {
File(it).exists()
}?.let { docker ->
dockerExecutable.set(docker)
}
}
Is there any target solution planned to solve this issue? For me and couple of my team mates exactly the same bug occurs with combination of JDK21 and IntelliJ. It works through the console.