I have the following pipeline script in Jenkins:
node {
withMaven(globalMavenSettingsFilePath: '/my/path/apache-maven-3.2.2/conf/settings.xml', jdk: 'JDK 1.8.0u92', maven: 'apache-maven-3.2.2', mavenSettingsFilePath: '/my/path/apache-maven-3.2.2/conf/settings.xml') {
sh '/my/path/apache-maven-3.2.2/bin/mvn clean install'
}
}
For this, I am getting:
nohup: failed to run command `sh`: No such file or directory
ERROR: script returned exit code -2
Why is this?
I am sure that the path to my Maven installation is correct. When I run a job without the pipeline, Maven builds with no errors and I can see that it uses the same path.
This might be the result of modifying PATH.
Check your script and Global Properties and remove modifications to PATH. It is now recommended to use PATH+extra instead. It would still be picked up, but without breaking actual PATH.
Related issue on Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-41339
In the end, I used shell instead of sh and it worked. No idea why, they don't have a proper API.
I would suggest to use it like this:
withMaven(
maven: 'M3',
mavenSettingsConfig: 'maven-settings-for-the-task',
mavenLocalRepo: '.repository') {
// Run the maven build
sh "mvn clean install"
}
Apart from that I would not use absolute paths to global settings.xml nor to user settings.xml. I would prefer using usage of "Config File Provider Plugin" which has the advantage to have the settings.xml on Master and available on all nodes.
See also the documentation: https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Maven+Plugin
This error comes when you are trying to run script copied from windows machine to unix machine.
YOU need to change the format to unix using : dos2unix <scriptname.sh> and the run your script in unix ./<scriptname.sh>
I have a windows jenkins slave and I have download apache-maven-3.3.3 on it.
It is located C:\Users\myUsername\Desktop\apache-maven-3.3.3 This is copy and pasted from the windows explorer on my Windows slave.
Then when I point at this location in Jenkins and run a build. I get this error
Couldn’t find any executable in C:\Users\myUsername\Desktop\apache-maven-3.3.3
I have also tried Couldn’t find any executable in C:\Users\myUsername\Desktop\apache-maven-3.3.3\bin
This works just fine on my linux slaves. What is the difference? Why is this not working?
Maven changed the name of the executable in Maven 3.3 from mvn.bat to mvn.cmd. Jenkins recognized mvn.cmd since Jenkins 1.613 (see this commit). If you are on an earlier Jenkins version you can add a symlink from mvn.bat to mvn.cmd on windows as a workaround.
The executable is in the \bin folder (namely, mvn.bat). Try to point Jenkins to C:\Users\myUsername\Desktop\apache-maven-3.3.3\bin
First
Under your Windows machine
1. create an Environment Virable named MAVEN_HOME and set its value to C:\Users\myUsername\Desktop\apache-maven-3.3.3.
2. Add %MAVEN_HOME%\bin into your System PATH
Second
Go to
http://your-jenkins-server/computer/your-windows-slave/configure -->Node Properties-->Tool Locations-->(Maven)maven
and set its value to C:\Users\myUsername\Desktop\apache-maven-3.3.3 as well.
Third
Reconnect your jenkins slave, then rerun your job.
Well for me it was wrong setting for maven. Go to configure, under post build action, go to advanced setting and there fix the Maven version to be used, i changed it to maven 3.3.3 and it worked.
I am using Windows. The accepted answers does not work for me. So, I have to create a new Maven in Jenkins and select the option "Install automatically". Then it works.
I used gradle build command in Centos 7 terminal and I got output:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler().
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
For me, killing the Gradle daemon (gradle --stop) really helped and fixed the issue.
Try setting your GRADLE_USER_HOME variable to a folder where you have valid access. Then this error will go away.
For ex: I faced the same issue today while I was running gradle clean command on a new slave machine.
My Gradle version was 2.3.
With --stacktrace, I came to know it was trying to create .gradle folder for storing Gradle's cache data (while I invoked Gradle to run clean task on the slave) and it was trying to create that folder under /some/location/where/gradle/exists OR some /path/location/xxx/yyy where the user which was running Gradle on the slave machine didn't have valid access to write (create folder/files).
i.e. the user which I used to connect from Jenkins machine to the slave didn't have write access to touch/mkdir anything in the default location (where Gradle thought, OK I should create .gradle folder here).
To fix it, I added the above GRADLE_USER_HOME variable in the slave's ENVIRONMENT Variable section. Now, as I have valid access in my home directory, I was OK.
Setting:
GRADLE_USER_HOME=~/gradle_2_3_cache/.gradle
resolved the issue.
You can set it to ~/.gradle as well. But I set it under a custom folder inside my ~ home directory (gradle_2_3_cache). This will help me in case I have another job/build run running on the same Slave machine but with a different Gradle version for ex: 2.5 etc version and if I want the .gradle cache for 2.3 and 2.5/x version in separate folders.
NOTE: When using parallel section within Jenkinsfile, it's best to avoid Gradle greatness (i.e. using same Gradle's cache i.e. using same GRADLE_USER_HOME) as otherwise, you'll land into a mine of interesting issues as listed here: Jenkins - java.lang.IllegalArgumentException: Last unit does not have enough valid bits & Gradle error: Task 'null' not found in root project
The Problem solved by simply using "sudo" and giving access to gradle to create a folder and write cache. use:
sudo ./gradlew
If you using wrapper gradlew, in root make directory .gradle_new
mkdir .gradle_new
chmod -R 777 .gradle_new
and run gradlew with arguments:
--project-cache-dir .gradle_new
Restarting the machine solved the issue.
I had the same problem.
For me it worked after I exclude the .gradle folder if you can not delete try to rename.
If you have just updated your JDK version and you have set up a Gradle wrapper in your project, you may want to double-check the wrapper version supports your new JDK. If not, consider removing wrapper-related files from the project (gradlew, gradlew.bat and gradle/wrapper/*) and re-generating them with the Gradle CLI, like so:
gradle wrapper --gradle-version <new-version-number>
e.g. gradle wrapper --gradle-version 4.10.2
This of course assumes your Gradle installation is up-to-date. If not, you will want to update that first.
I got the same error, got rid of it by using the correct version of Java / JDK. I was trying to build a Java 8 project with the Java 11 JDK. Check which version of Java JDK you are using.
To develop projects with different Java versions in parallel I now use jEnv to manage the different JDK versions: http://www.jenv.be/
This is a permission issue.
do a
gradle wrapper --stacktrace
you should see something like this
Failed to create parent directory '/home/cloud_user/my-project/gradle' when creating directory '/home/cloud_user/my-project/gradle/wrapper'
the user, cloud_user, has no permission to the directory
make cloud_user owner of the folder
sudo chown -R cloud_user:cloud_user /home/cloud_user/my-project/
I got this error when running code in IntelliJ Idea, and
gradle --stop
really not helped, as it said that "No Gradle daemons are running."
But simple kill of all gradle processes helped:
ps aux | grep gradle
kill -9 $PID
Permission issue. This fixed the issue for me:
sudo chown -R $USER dir
For me this was to do with Java versions. I have Java 10 installed and as the default Java on my system. Setting a JAVA_HOME pointing at Java 8 was sufficient for the project (graphql-spring-boot) to build.
If using the "Invoke Gradle script" build step, click on Advanced to reveal additional options. Locate "Force GRADLE_USER_HOME to use workspace" and check it.
If anyone is still struggling with this, my issue was caused by Microsoft preventing Java from running due to Controlled Folder Access security restrictions.
I didn't get the popup notification since my computer is set to Do Not Disturb Mode. Once I allowed access, Gradle ran fine.
For future reference.
I had the same problem, the issue was that the antivirus was blocking OpenJdk platform binary and java.exe which prevented android studio from being able to modify the files
I ran into this exception when trying to build a project that was mounted as read-only filesystem in a VM. The project set its own gradle cache so changing GRADLE_USER_HOME did not work. I had to change the filesystem to be read/write.
You Just Have to Run it under the super user (sudo ....) it works for me
If you run Docker-in-Docker and mount the project directory from docker host directly to docker container:
-v ${PWD}:/path_to_project -w /path_to_project
the owners are different and docker container user (either gradle or root) can't override/delete ./buildSrc/build or ./build/
One of the fixes - copy the sources inside the container to temporary directory and build there.
Smth like this (first mounted to project, but then copied to project-copy to "decouple" with the host system real files and run the build in the copy):
docker run -v "${PWD}":/home/gradle/project -w /home/gradle/project-copy \
--rm \
--entrypoint sh \
gradle:5.5.1-jdk11 \
-- -c "cp -r -T /home/gradle/project ./ && ./gradlew build"
In my case I had bad credentials to private Maven repository. JIdea does not show the inner exception but running gradle build reveals the problem immediately.
I used a Gradle project in Eclipse, Eclipse's Gradle was giving that error. When I installed NetBeans and its Gradle Plugin, the problem has gone, project was building okay. Another way to circumvent this error was using commandline ./gradlew , project also built successfully.
It seems that Eclipse's era is over, they appear to be unable to follow the progress.
This can happen if you run Gradle commands from separate terminals at the same time - I assume Gradle somehow locks ~/.gradle when it is running to prevent any problems.
I had that same error, while running gradle with java 14 (openjdk) as my default java implementation. Setting default java back to java 8 solved the issue
sudo update-alternatives --auto java
just run (taskkill /im java.exe /f) in command
In my case the error was different but I landed here, my error was:
Could not create service of type ExecutionHistoryStore using ExecutionGradleServices.createExecutionHistoryStore().
> Timeout waiting to lock execution history cache (/Volumes/Extreme SSD/FlutterProject/test/android/.gradle/6.7/executionHistory). It is currently in use by another Gradle instance.
Owner PID: unknown
Our PID: 94001
Owner Operation: unknown
Our operation:
Lock file: /Volumes/Extreme SSD/FlutterProject/test/android/.gradle/6.7/executionHistory/executionHistory.lock
It happens when you try to run flutter run from two separate terminals.
So I solved it by executing cd <projectPath> && flutter run from the active terminal which I was using first.
Basically, while executing some Gradle command, in this case building an android file, the terminal locks down some Gradle PID, so either you stop them or just simply use that terminal.
in my case manual removing the .gradle and .idea folders helped me
you can find them in the Android Studio if Project view selected
after this just clean and rebuild app
kill -9 'pid' solved the issue. pid can be found in the error log
To fix this issue, restarting your PC is the main solution
I got the same issue and for me worked below command.
./gradlew --stop
After that restart my system and wipe data of simulator and run again everything works fine.
I have a jenkins git job to pull down code from github. Jenkins tells me the job / project is successful. But I can't see the code anywhere on my file system (osx).
Where should it be?
If you used the default location for the JENKINS_HOME directory where Jenkins stores all its data, the code should be under
/Users/jenkins_user/.jenkins/job_name/workspace
where jenkins_user is the account that runs the Jenkins server and job_name s the name of your build job.
Additionally, within the first few lines of the "Console Output" for any build, you should see on which machine and in which directory the build occurred, e.g.
"Building on master in workspace /Users/jenkins_user/.jenkins/job_name/workspace"
This happens for both: maven projects, and freestyle projects, when maven target is envoked, it tries to execute mvn using absolute path.
[MY-Job] $ tools/Maven/Jenkins_Private_Maven/bin/mvn -f cc/pom.xml -Ddeploy_env=xxx.dev.prv -Dbranch=dev -D-Dsmdist.target=/opt/builds -U clean test -DtestGroups=unit,delegate -Do verride:server=xxx.dev.prv
FATAL: command execution failed
java.io.IOException: Cannot run program "tools/Maven/Jenkins_Private_Maven/bin/mvn" (in directory "workspace/MY-Job"): java.io.IOException: error=2, No such file or directory
I can see that mvn is installed at user's home :
/home/jenkins/tools/Maven/Jenkins_Private_Maven/bin/mvn
but it's trying to run it from the workspace:
/home/jenkins/workspace/MY-Job/tools/Maven/Jenkins_Private_Maven/bin/mvn
Add the default maven installation under (Jenkins -> configuration)
Goto the failing job and make sure you choose the default maven installation from dropdown
Run the job. Success!
Are you sure you have set up Maven in Jenkins -> configuration like this
I have hunch you have a accidental **"."** current directory reference somewhere in your maven set up.
This looks like an auto installed Maven by Jenkins. In which case the previous answers are not correct.
It would seem in this occasion that you have not specified a "remote fs root" for your slave in the salve setup - later versions of Jenkins flag not setting this up correctly as an error.
in Jenkins 2.43:
Manage Jenkins -> Global Tool Configuration -> Maven