I am using jibdockerbuild to build an image to run into Docker for windows.
It's as simple as gradle jibdockerbuild using the command line.
I am making a script to build multiple images and here is how it looks like
pushd sevice0
gradle jibDockerBuild
popd
sleep 2
pushd sevice1
gradle jibDockerBuild
popd
sleep 2
pushd service2
gradle jibDockerBuild
popd
The issue with this is as follows:
Gradle randomly fails to start due to being busy even after finishing the command given.
Using the command line scenario (non-script) I just have to re-execute the command and it will work fine error message would be something like Daemon busy
The naif solution I had is to add sleep 2 which will give Gradle extra time to finish.
But if I have a slower machine, The sleep 2 will keep the issue.
Had in mind to use Gradle --stop after each gradle jibdockerbuild but it will even take more time to start Gradle Daemon again with each gradle jibdockerbuild command.
Question :
Is there a configuration I can add so Gradle won't fail to start a new daemon for each command? something like Parallel?
Is there any way I can do a fast check with my script before I run the next gradle jibdockerbuild ?
Am simply looking for a way to build all the images over any machine, without having any failure possibilities.
Additional info :
Gradle version 6.9
java 11.0.16 2022-07-19 LTS
Docker version 20.10.16, build aa7e414
Related
IntelliJ IDEA 2021.1 and 2021.2 leaves the Gradle Daemon running when I exit the program. I would like to know if there is a way to momentarily stop or restart the Gradle Daemon from within IntelliJ without exiting. Gradle has a lock on files that doesn't go away when simply closing IntelliJ. The only way to get it to release the lock is to run gradle --stop from the version of Gradle that is currently running. The approaches I've found so far are far less than ideal. I'll share them in case they help anyone else, but I'm hoping there's a better way.
If I manually browse to my User Home.gradle\wrapper\dists\gradle-x.y.z-all<hash>\gradle-x.y.z\bin for the version of Gradle that I know IntelliJ is using, then I can manually run that gradle command with --stop flag and it will stop the daemon. So, yeah I guess I could create a batch script for this, but the fact that it is stored in such a buried directory involving some sort of hash code, I don't really want to have to change this script for different systems.
In InteliJ IDEA, If I click the "elephant" looking button at the top of the gradle menu called "Execute Gradle Task" it brings up a command line that starts with "gradle", but it only accepts established task names, it doesn't accept "gradle --stop". It gives the error Unknown command-line option '--stop'.
As a less than ideal work around, I have copied the gradle-x.y.z folder from near the end of that path to c:\Gradle\ and I have added that version's bin folder to the PATH environment variable. So, at least, I can open up a command prompt and run gradle --stop for now. This becomes problematic when I want my default / command line accessible gradle version to be different from the project I am working on. Yeah I could create a bunch of custom batch scripts that point to all different versions. That doesn't sound like fun. I have a hard time believing that I can't do something within IntelliJ to get the currently running gradle daemon to shutdown.
IDE does not kill Gradle daemon, because this demon can be reused by another build, including when doing a build from the command line.
There is an action Show Gradle Daemons (you can call it from Help | Find Action action):
It will show you the list of Gradle daemons with the ability to stop them:
I canceled a running Gradle build and now I get the following message whenever I restart it:
Could not create service of type FileHasher using BuildSessionServices.createFileHasher().
> Cannot lock file hash cache (/data/.gradle/6.4.1/fileHashes) as it has already been locked by this process.
try running (if gradle in installed on your machine and in the PATH)
gradle --stop
or
./gradlew --stop
in your project directory
from the command line. worked for me.
run
gradlew --stop
in the terminal for Windows
For Mac user run
./gradlew --stop
from root of you project
The solution is to look for the gradle process and to kill it. In my case I had to look for a running java process.
So in htop I searched for java and terminated it. That solved my problem.
On my Linux machine in my root project directory I have the Gradle Wrapper
Project
|
+ src
|
+ gradlew
and when I run any command with gradlew there is no output, like for example when I print the version, there is no version printed
./gradlew --version
or when I check tasks, no tasks are displayed
./gradlew --tasks
or when I try to build the project, no out/ directory is created
./gradlew deploy
but when I click
Build > Build Project
in my Intellij IDE, the project does build, just not when I try to use Gradle from the command line.
So I have no idea what's going on with my gradle wrapper. Am I using the wrapper incorrectly?
My gradle wrapper which is just a Bash script, was empty ... somehow it's contents were deleted, so the script was running and nothing was happening. Good times.
It happened to me as well, the script was totally empty. The fix for me was to go to the gradle tab in IntelliJ and click on "Wrapper" under "Build setup".
After this my gradlew script got properly initialized.
I'm a relatively new user with Gradle, I'm working for the first time on a project (and first time with JHipster as well).
To run my application through the terminal, I execute the following command:
gradlew.bat
But at each new modification I have to kill the application ctrl + c and run it again.
I already tried using the command gradlew.bat -t build -x test (I don't want to run test each time) and gradlew.bat --continue, but both did not work.
As the bootRun task, which is the default task gradle doesn't know when to start watching, so it is not possible with gradle only. Using your ide (e.g. intellij) and the springboot devtools it is possible.
Start the application from our ide
Make changes in the code
In intellij press ctrl + F9 to compile the code and the application should restart
When you want to do it with gradle only you need two terminals and start e.g. javaCompile in continuous mode and bootRun in another terminal. The boot devtools will take care of restarting the application when it detects the newly compiled files.
gradlew compileJava -t in on terminal
gradlew bootRun in another terminal
How do I determine why my Gradle Daemon died? The only message I get isL
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
This occurs in an active build. Several steps will finish and a step will appear to be active and then the build fails.
This began after moving our memory args (Xmx Xms PermGen) from a shell script that called gradlew to gradle.properties and calling gradlew directly.
build.sh
export GRADLE_OPTS="\"-Xmx1024m\" \"-Xms256m\" \"-XX:MaxPermSize=256m\""
export JAVA_HOME="/usr/local/java/jdk1.6"
exec ./gradlew "$#"
Addition to gradle.properties
org.gradle.java.home=/usr/local/java/jdk1.6/
org.gradle.jvmargs=-Xmx1024m -Xms256m -XX:MaxPermSize=256m
After this change Gradle warns:
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: http://gradle.org/docs/2.2.1/userguide/gradle_daemon.html
And even though we don't ask it to, the build is running in a daemon, which ultimately fails.
Gradle build daemon disappeared unexpectedly most frequently occurs when something else kills the long-running Gradle Daemon process and the client process (the Daemon uses local TCP connections to communicate) tries to send a message and gets no response.
For example, running gradle --stop or killall java while a build is occurring will reproduce this problem.