Summary: A month or two ago we started noticing our Jenkins builds stalling indefinitely. When a build spins up, our Jenkins Shared Library creates a new docker container on a virtual machine and executes the library code to build our service, usually including a maven build. We sporadically see a build or two stall indefinitely on one of various Maven goals (and only maven goals, as seen below). Sometimes this is happens on single build on a virtual machine, but it is most egregious when we run multiple builds at the same time. Some will build, others will stall. All builds on the same virtual machine share an .m2 repository so we don't download dependencies every time.
We are using maven 3.8.1 running in an ubuntu 18.04 container. We're looking for possible leads as we've exhausted all of ours.
We tried upgrading to maven 3.8.2 with no luck, we tried looking into this similar issue but its solution did not apply to us: Jenkins docker container simply hangs and never executes steps
We've also tried having each node have its own maven repository and that didn't work, so we ruled out read/write conflicts.
Details:
Some of the places it stalls:
Mvn help:evaluate after "Picking up Java_Tools_Options...",
Mvn set:property,
On checking on updates from virtual,
On actually downloading from artifactory.
These are a couple example of where it stalls:
[2022-02-22T17:39:15.452Z] + mvn versions:set-property -Dproperty=my.version -DnewVersion=4.0.1 -DgenerateBackupPoms=false -X --debug
[2022-02-22T17:39:15.452Z] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400
And
[2022-03-03T13:27:01.046Z] + mvn clean install -P snapshot -Dmaven.test.skip=true -Dbuild.number=32 -U
[2022-03-03T13:27:01.046Z] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 -Djenkins.branch.WorkspaceLocatorImpl.PATH_MAX=0 -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.HEARTBEAT_CHECK_INTERVAL=86400
[2022-03-03T13:27:02.425Z] [INFO] Scanning for projects...
[2022-03-03T13:27:04.913Z] [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) # sample-child-java ---
[2022-03-03T13:27:05.481Z] Downloading from virtual: https://my.artifactory/org/codehaus/plexus/plexus-java/0.9.10/plexus-java-0.9.10.pom
When we turn on debug mode for maven, we only get a little extra information before it stalls:
02-22T17:39:20.880Z] [DEBUG] Reading global settings from /opt/maven/conf/settings.xml
[2022-02-22T17:39:20.880Z] [DEBUG] Reading user settings from /home/myUser/.m2/settings.xml
[2022-02-22T17:39:20.880Z] [DEBUG] Reading global toolchains from /opt/maven/conf/toolchains.xml
[2022-02-22T17:39:20.880Z] [DEBUG] Reading user toolchains from /home/myUser/.m2/toolchains.xml
[2022-02-22T17:39:20.880Z] [DEBUG] Using local repository at /home/myUser/.m2/repository
[2022-02-22T17:39:21.144Z] [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for /home/myUser/.m2/repository
After about 6 hours of stalling, the logs will usually show one of these statements:
Cannot contact myVirtualMachine6: Remote call on myVirtualMachine6 failed. The channel is closing down or has closed down
Wrapper script does not seem to be touching the log file in /home/jenkins/workspace/myService#tmp/durable-7db8f58b
(JENKINS-48300: if on an extremely laggy filesystem, consider - HEARBEAT_CHECK_INTERVAL=86400)
We tried using the withMaven() from the Maven Integration Plugin, but even that did not solve our problem:
11:14:07 + mvn versions:set-property -Dproperty=myService.version -DnewVersion=9.9.9-RC1 -DgenerateBackupPoms=false
11:14:07 Picked up JAVA_TOOL_OPTIONS: -Dmaven.ext.class.path="/home/jenkins/workspace/myService#tmp/withMaven368661c2/pipeline-maven-spy.jar" -Dorg.jenkinsci.plugins.pipeline.maven.reportsFolder="/home/jenkins/workspace/myService#tmp/withMaven368661c2"
11:14:10 [INFO] [jenkins-event-spy] Generate /home/jenkins/workspace/myService#tmp/withMaven368661c2/maven-spy-20220308-161411-4457772303541115170084.log.tmp ...
When we add a tee command to our withMaven() maven commands, the output where it stalls is just:
[INFO] [jenkins-event-spy] Generated /home/jenkins/workspace/myService#tmp/withMavena1de258e/maven-spy-20220308-192941-7666252427488201541499.log
[INFO] [jenkins-event-spy] Generate /home/jenkins/workspace/myService#tmp/withMavena1de258e/maven-spy-20220308-193003-7826277450333225168004.log.tmp ...
Our Jenkinsfile is just this and calling our maven script:
agent {
docker {
label 'myVirtualMachine6'
image 'myImage'
registryUrl 'xxxx'
registryCredentialsId 'yyyy'
args '-v maven-repo:/home/myUser/.m2/repository/ -v /var/run/docker.sock:/var/run/docker.sock'
}
}
Related
I have a custom Docker container in which I perform build and test of a project. It is somehow integrated with Travis CI. Now I want to run the Coverity scan analysis from within the Travis CI as well, but the tricky part is (if I understand the Coverity docs correctly), that I need to run the build. The build, however, runs in the container.
Now, according to the cov-build --help
The cov-build or cov-build-sbox command intercepts all calls to the
compiler invoked by the build system and captures source code from the
file system.
What I've tried:
cov-build --dir=./cov docker exec -ti container_name sh -c "<custom build commands>"
With this approach, however, Coverity apparently does not catch the calls to the compiler (it is quite understandable considering Docker philosophy) and emits no files
What I do not want (at least while there is hope for a better solution):
to install locally all the necessary stuff to build in the container
only to be able to run Coverity scan.
to run cov-build from within the container, since:
I believe this would increase the docker image size significantly
I use Travis CI addon for the Coverity scan and this would
complicate things a lot.
The Travis CI part just FWIW, tried all that locally and it doesn't work either.
I am thrilled for any suggestions to the problem. Thank you.
Okay, I sort of solved the issue.
I downloaded and modified ( just a few modification to fit my
environment ) the script that Travis uses to download and run Coverity
scan.
Then I installed Coverity to the host machine (in my case Travis
CI machine).
I ran the docker container and mounted the directory where the
Coverity is installed using docker run -dit -v <coverity-dir>:<container-dir>:ro .... This way I avoided increasing the docker image size.
Executed the cov-build command and uploaded the analysis using
another part of the script directly from docker container.
Hope this helps someone struggling with similar issue.
If you're amenable to adjusting your build, you can change your "compiler" to be cov-translate <args> --run-compile <original compiler command line>. This is effectively what cov-build does under the hood (minus the run-compile since your compiler is already running), and should result in a build capture.
Here is the solution I use:
In "script", "after_script" or another phase in Travis job's lifecycle you want
Download coverity tool archive using wget (the complete Command to use can be found in your coverity scan account)
Untar the archive into a coverity_tool directory
Start your docker container as usual without needing to mount coverity_tool directory as a volume (in case you've created coverity_tool inside the directory from where the docker container is started)
Build the project using cov-build tool inside docker
Archive the generated cov-int directory
Send the result to coverity using curl command
Step 6 should be feasible inside the container but I usually do it outside.
Also don't forget the COVERITY_SCAN_TOKEN to be encrypted and exported as an environment variable.
A concrete example is often more understandable than a long text; here is a commit that applies above steps to build and send results to coverity scan:
https://github.com/BoubacarDiene/NetworkService/commit/960d4633d7ec786d471fc62efb85afb5af2bed7c
I am somewhat familiar with Gauge testing tool and am now working on executing it via Jenkins.
First: i set gauge --version in the "Execute Windows Batch Command" field. This was the output:
Started by user anonymous
Building in workspace C:\jenkins\workspace\Run_Gauge_Test
[Run_Gauge_Test] $ cmd /c call C:\WINDOWS\TEMP\hudson8329964667758110371.bat
C:\jenkins\workspace\Run_Gauge_Test>gauge --version
Gauge version: 0.6.2
Plugins
-------
No plugins found
Plugins can be installed with `gauge --install {plugin-name}`
C:\jenkins\workspace\Run_Gauge_Test>exit 0
Finished: SUCCESS
Compare this to the output I get if I run Gauge directly in command line:
C:\jenkins\workspace\Run_Gauge_Test>gauge --version
Gauge version: 0.6.2
Plugins
-------
html-report (2.1.1)
java (0.5.1)
xml-report (0.1.3)
So i put the same command in a batch file and ran it only to get the "no plugins found" message again.
As a last option I ticked the Use custom workspaceand set my directory to a folder where I usually run gauge tests from command line but still it is "no plugins found"
Then i tried running it as a shell command. Output:
Started by user anonymous
Building in workspace C:\jenkins\workspace\Run_Gauge_Test
[Run_Gauge_Test] $ sh -xe C:\WINDOWS\TEMP\hudson211231385407124893.sh
The system cannot find the file specified
FATAL: command execution failed
java.io.IOException: Cannot run program "sh" (in directory "C:\jenkins\workspace\Run_Gauge_Test"): CreateProcess error=2, The system cannot find the file specified
at java.lang.ProcessBuilder.start(Unknown Source)
(truncated)
at hudson.model.Executor.run(Executor.java:404)
Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.<init>(Unknown Source)
at java.lang.ProcessImpl.start(Unknown Source)
... 16 more
Build step 'Execute shell' marked build as failure
Finished: FAILURE
Of course, I am going to actually run the gauge tests(and it doesnt work) rather than just get the version; but I thought it would be simpler to troubleshoot why it doesnt get plugin details correctly.
Any clues?
Gauge plugins should be installed via user/admin account with which the Jenkins agent executes commands. Have a look at following doc for more on integrating with GoCD and few other CI tools.
https://docs.gauge.org/latest/howto/index.html#tutorials
Long answer:
Currently, Gauge executable is installed at system level. Whereas Gauge plugins(language runners, reporting plugins etc) are installed at a user level. So if you install plugins as one user manually and on CI if task is run against different user, gauge will not be able to find plugins.
To fix this, you should run plugin install commands from the account with which CI runs. Or as Srikanth's comment says, you can have gauge --install-all task in pipeline. This installs all required plugins on the fly.
I suspect that you are installing and using Gauge as different users. As with a lot of CI tools, often the tasks are executed under a different users than one would use to log into the agent.
Currently the way Gauge works is: gauge.exe is available at a system level. However, the plugins are installed at a user level.
So if you login as user1 and do gauge --install java, gauge --version will list java as a plugin only when you are logged in as user1.
This is also true if you are running your CI agent under a local system account.
One way you can address this is if you include setup as a task in your pipeline, i.e. have a gauge --install-all from your project root before attempting to run your specs.
I try to scan Jhipster generated code with Sonarqube during a Jenkins build.
My configuration is the following:
Gitlab as Docker Container
Jenkins 2 as Docker Container
Sonarqube 5.4 (higher is not permitted with MariaDB; right?) as Docker Container
This is a fresh install and all systems are communicating together.
When running builds, Jenkins is alerting about duplicates references in the 'bower_components' repository.
WARN: Too many duplication references on file
[moduleKey=Challenge1:0.1-HENDRIX,
relative=src/main/webapp/bower_components/angular-i18n/angular-locale_vun-tz.js,
basedir=/var/jenkins_home/workspace/Challenge-1] for block at line 20.
Keep only the first 100 references.
My problem is that I do not get the reasons why is alerting about it since few exclusions have been set at different levels:
1) Within pom.xml
<sonar.exclusions>src/main/webapp/content/**/*.*, src/main/webapp/bower_components/**/*.*, target/www/**/*.*</sonar.exclusions>
2) Within Jenkinsfile
node {
...
stage 'scan'
sh "${sonarqubeScannerHome}/bin/sonar-scanner -e -Dsonar.host.url=http://sonarqube:9000 -Dsonar.projectKey=Challenge1:'0.1-HENDRIX' -Dsonar.projectName='Challenge 1' -Dsonar.projectVersion='0.1-HENDRIX' -Dsonar.sources='src/' -Dsonar.coverage.exclusions=**/bower_components/**"
}
3) On sonarqube customizing itself (Analysis Scope).
EDIT:
This "non-exclusion" was originally leading to a memory dump that I could solved by extending the memory on sonarqube (sonar.properties).
sonar.web.javaOpts=-Xmx2048m -Xms512m -XX:MaxPermSize=160m -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true
However, I a still am afraid that extending memory isn't the appropriate solution and I must be able to exclude some parts of code. What should I do to remove bower components from the scan analysis? (I probably made something wrong).
My mistake: I was using -Dsonar.coverage.exclusions instead of -Dsonar.global.exclusions
I have created maven based web application so after created application i am getting two errors in pom.xml which are
1.Multiple annotations found at this line:
- Failure to transfer org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted
until the update interval of central has elapsed or updates are forced. Original error: Could not transfer artifact org.apache.maven.plugins:maven-resources-plugin:pom:2.6 from/to central (http://
repo.maven.apache.org/maven2): null to http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.6/maven-resources-plugin-2.6.pom
2.Multiple annotations found at this line:
- Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (execution: default-testCompile, phase: test-compile)
- Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (execution: default-compile, phase: compile)
- CoreException: Could not calculate build plan: Plugin org.apache.maven.plugins:maven-compiler-plugin:3.1 or one of its dependencies could not be resolved: Failed to read artifact descriptor for
org.apache.maven.plugins:maven-compiler-plugin:jar:3.1: ArtifactResolutionException: Failure to transfer org.apache.maven.plugins:maven-compiler-plugin:pom:3.1
Could you please let me know what needs to be done for resolving the issue
If you are facing the same issue I described in my comment above then it seems I could fix it by running mvn eclipse:eclipse with working directory set to Eclipse project folder i.e.
$ cd /path/to/eclipse/workspace/Project
$ mvn eclipse:eclipse
Does this work for you ? Maybe your environment is different . Providing more details might help others to understand your problem even better so as to offer useful suggestions .
I had similar problem Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile (execution: default-testCompile, phase: test-compile).
To Fix (apart from installing M2E plug-in and all):
Ensure installed maven is > 3.1 (using mvn -v). If not, you need to upgrade.
Ensure eclipse is pointing to correct maven location (Window->Preferences->Maven->Installations)
On Command prompt, go to project home directory and run mvn eclipse:clean and mvn eclipse:eclipse
Disable and enable Maven nature in eclipse (Right click on project, goto Maven -> Disable Maven Nature. To enable, Right click on project goto Configure -> Convert to Maven Project)
I've installed the Gradle plugin for Jenkins. When I try to build the project I get the following error:
[workspace] $ gradle clean -b build/build.gradle
FATAL: command execution failed
java.io.IOException: Cannot run program "gradle" (in directory "/Users/Shared/Jenkins/Home/jobs/test/workspace"): error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
at hudson.Proc$LocalProc.<init>(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:707)
at hudson.Launcher$ProcStarter.start(Launcher.java:338)
at hudson.Launcher$ProcStarter.join(Launcher.java:345)
at hudson.plugins.gradle.Gradle.performTask(Gradle.java:201)
at hudson.plugins.gradle.Gradle.perform(Gradle.java:97)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:695)
at hudson.model.Build$RunnerImpl.build(Build.java:178)
at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:465)
at hudson.model.Run.run(Run.java:1404)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(UNIXProcess.java:53)
at java.lang.ProcessImpl.start(ProcessImpl.java:91)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:453)
... 16 more
Build step 'Invoke Gradle script' changed build result to FAILURE
Build step 'Invoke Gradle script' marked build as failure
Finished: FAILURE
Running the task $ gradle clean -b build/build.gradle from the command line works as expected.
I had the same issue and found that the problem for me was the gradle version in the project configuration. It was set to Default and when I set it to the gradle version I was pointing to in the plugin configuration in the Manage Jenkins > Configuration Options, It found gradle and worked properly.
This is a difficult issue to debug and I hope this saves someone else some time.
Solution Mastering_the_Object pointed out worked form me too, just to clarify steps there:
just installing Gradle plugin in Jenkins is not enough, you must also go to:
Jenkins->Manage Jenkins->Configure Jenkins->Configure system.
Under "Gradle Installations" type in name (it appears as version in project configuration), check "Install automatically" and select version. Then you can select that "Gradle version" in project configuration.
I was getting this error using the Gradle wrapper, was able to fix my broken build as follows:
Go to Manage Jenkins -> Global Tool Configuration -> Gradle -> Add Gradle, give it a name
Go to Jenkins -> (your job) -> Configure -> Build, choose "Invoke Gradle" and change the Gradle version from (Default) to the named version
When running Gradle on a CI machine such as Jenkins, it's most convenient to use the Gradle Wrapper.
On your development machine, stand in your root project directory and run
gradle wrapper
Then, check in the resulting files into your source control system. After that, you don't have to install anything on your Jenkins server if you need to change Gradle versions. Just configure your Jenkins job like this:
Quoting from the Gradle User Guide:
By distributing the wrapper with your project, anyone can work with it
without needing to install Gradle beforehand. Even better, users of
the build are guaranteed to use the version of Gradle that the build
was designed to work with. Of course, this is also great for
continuous integration servers (i.e. servers that regularly build your
project) as it requires no configuration on the server.
The jenkins can not find the gradle executable. I have never made gradle wrapper to work. Please follow the following steps:
Download gradle ( http://gradle.org/downloads),
unpack it to, e.g., /usr/local/lib/gradle ,
open /etc/profile and add the following two lines:
export GRADLE_HOME=/usr/local/lib/gradle
export PATH=$PATH:$GRADLE_HOME/bin
It works for my jenkins installation.
ps. I answer this old question, because it is a common issue when setting up gradle with jenkins. I have spent some time trying to make the gradle wrapper work without success before.
Used both #Skarab & a number of other solutions here to get it to work.
Download gradle ( http://gradle.org/downloads),
unpack it to, e.g., /usr/local/lib/gradle ,
open /etc/profile and add the following two lines:
export GRADLE_HOME=/usr/local/lib/gradle
export PATH=$PATH:$GRADLE_HOME/bin
Then under Manage Jenkins > Configure system > Gradle, defined GRADLE_HOME and gave that gradle installation a name
Then, {this could be a bug} for the project, change gradle version from Default to the one I defined above
As others have noted, this is because Jenkins can't find the gradle executable.
None of the published solutions worked for me, but I was able to fix the problem by adding the gradle bin dir to the path set in the .bashrc for the build account on the build slave. Modifying the .profile failed, and setting PATH in the jenkins node configuration also failed.
Some posts will suggest setting the gradle path in the tools menu, but no gradle entry was available there either (perhaps due to regressions / design changes in the gradle plugin?).
In any case, the best test I found (short of running the build again and watching for failure) was to run env over ssh:
ssh <host> env
and check the PATH variable defined that way; if gradle isn't in that path, you probably won't be able to run it from jenkins.