We use a parallel gradle build in our ci server. But finding the cause of the build failure is sometimes a pain, because one has to dig through the gradle output to find the real problem. I would like to improve that.
For example one of the gradle tasks uses yarn. If this task fails gradle reports the following in the jenkins console:
10:27:27 * What went wrong:
10:27:27 Execution failed for task ':foo-web:yarn'.
10:27:27 > Process 'command '/home/jenkins/workdir/workspace/foo/foo-web/.gradle/yarn/bin/yarn'' finished with non-zero exit value 1
Then one has to scroll up a lot of lines to find the output of yarn due to parallel tasks being finished, just to find out yarn could not download a dependency.
Can we change the gradle build failure reporting so that it will append the error output of the failed task at the end of the build output to the failure report? Or is there some way to get gradles failure reporting and the output of the failed task more closely together?
Related
I'm building maven project on Jenkins (version 2.263.4, not the last but not so far).
It's a git project with pipeline configuration and webhook from bitbucket when push is done on the project.
So when a developper create a branch and another one a pull request, i have 2 build in parallel. Domain test running in about 45min.
And sometimes(not always), i have this error :
Command was /bin/sh -c cd /jenkins/workspace/a-hub_test-plantage-jenkins_PR-1/server/project-core/project-core-domain && /jenkins/tools/hudson.model.JDK/jdk11/jdk-11.0.2+9/bin/java -Xmx1500M -jar /jenkins/workspace/a-hub_test-plantage-jenkins_PR-1/server/project-core/project-core-domain/target/surefire/surefirebooter15630998754365374145.jar /jenkins/workspace/a-hub_test-plantage-jenkins_PR-1/server/project-core/project-core-domain/target/surefire 2021-05-04T12-39-54_622-jvmRun1 surefire5846464826560071036tmp surefire_13691263758446667285tmp
Error occurred in starting fork, check output in log
14:46:13 [ERROR] Process Exit Code: 1
14:46:13 [ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
14:46:13 [ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
14:46:13 [ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
If i re run the buildin error, it work.
I'm using maven-surefire 2.22.2.
I try to configure it following many thread on stackoverfow, but nothgin work. I try with forkMode none or something else, it work but i loose coverage because jaccoco need fork to work. So i'm stuck.
What can i do to help me to debug this problem?
I don't understand why build failed when another one is building because for me Jenkins work on different working folder, no? so why the problem appear when i'have multiple build in parallel?
thanks for help
I find an hs_err_pid.log in jenkins near source code and i see out of memory! i see that my test was launch with -Xmx1500Mo and problem occured when i launched multiple branch/pr, so jenkins use all of the memory and failed all build during fork...i decrease -Xmx and all seems to work.
Enviroment:
gradle-6.5.1
Kotlin
JSF
Hello everyone.
I had to move from Intellij because my licence expired And I was trying to buil my project using Gradle(As I was already doing before) using VS Code.
When I try to run my project with the usual gradle build -info --build-cache so when I try to compile my kotlin code it gets stack in the same part every single time:
> Task :compileKotlin
Deleting stale output file: C:\Users\Usuario\Desktop\cloud\build\classes\kotlin\main
Build cache key for task ':compileKotlin' is 3bd7d5460a493fb5a0944ec8a3be0e80
Task ':compileKotlin' is not up-to-date because:
No history is available.
The input changes require a full rebuild for incremental task ':compileKotlin'.
Using Kotlin/JVM incremental compilation
<-------------> 0% EXECUTING [4m 16s]
> :compileKotlin
It dosen't throw an error, it just stays like so for hours and hours.
I also updated from gradle-5.2.1(It didn't ork in that version neither) but when running the scan my gradle.build doesn't seem to have any problems, just some deprecated but still useful instructions: My scan results
Does anyone have an idea of what could be happening?
I have a Hudson server that runs maven 3 jobs to compile Java code. In one instance, a particular job's build log indicates that the compilation and unit tests all ran successfully, and the build completed in a successful state and another chained job was called, all indicated that Hudson believed the job to be successful. The log shows:
20:44:11 [INFO] BUILD SUCCESS
20:44:11 [INFO] ------------------------------------------------------------------------
20:44:11 [INFO] Total time: 1:35:43.774s
20:44:11 [INFO] Finished at: Mon Mar 24 20:44:11 CDT 2014
20:44:40 [INFO] Final Memory: 51M/495M
20:44:40 [INFO] ------------------------------------------------------------------------
20:44:42 channel stopped
20:44:42 [locks-and-latches] Releasing all the locks
20:44:42 [locks-and-latches] All the locks released
20:44:43 Archiving artifacts
20:45:33 Updating JIRA-1234
20:45:33 Description set: 1.23.567
20:45:33 Labelling Build in Perforce using ${BUILD_TAG}
20:45:33 [jobname] $ /usr/local/bin/p4 -s label -i
20:45:33 Label 'hudson-jobname-45' successfully generated.
20:45:33 [DEBUG] Skipping watched dependency update; build not configured with trigger: jobname #45
20:45:33 Finished: SUCCESS
However, the Hudson job page shows a "red ball" and that job run is listed as "Last failed build (#45)" on the job page. When I look at the hudson#hudson:~hudson/jobs/jobname/builds/45/build.xml file, there is a line that says
<result>FAILURE</result>
Assuming this was where the final result was captured, I changed this to
<result>SUCCESS</result>
and reloaded the page, but the red ball is still showing on the job page for that instance. I have not restarted the server to attempt to re-read the info from disk.
To be fair, there were some environmental issues around this build. Some hours later, I got a message that more than one Hudson server instance was running against the same disk image and confirmed this with
ps -ef | grep hudson.war
on the server console, showing two running processes. The job page says this run "Took 0 ms", even though the log says "Total time: 1:35:43.774s". This is Hudson ver. 2.2.1 running on "CentOS release 5.4 (Final)".
My questions:
What are the criteria for each of the job statuses? (Stable, Failed, Unstable, Aborted and Disabled statuses)?
When and where is that data captured in the running server, and can it be modified?
You have too many questions in one post.
As for "What are the criteria for each of the job statuses? (Stable, Failed, Unstable, Aborted and Disabled statuses)?"
Disabled is when a project/job is disabled from configuration (done by user with permissions). This is not a run status.
The rest are Job Run statuses:
Aborted is when a run has been cancelled/aborted. This happens when a user (with permissions) clicks the red cross button to cancel a running build. I believe SCM checkout failure also causes aborted status (but not too sure about that)
Unstable is a special status that can be applied to the job run. Usually this is done by job configuration (such as Maven) or through plugins such as Text-finder plugin. I am not aware of a way to induce unstable status through command line. Maybe through a groovy script, like plugins do. Most of the times, unstable is set by the job configuration itself, indicating failed test.
Stable and Failed are the direct result of Build Step's exit code. If the build step, such as Execute Shell, exits with exit code 0, the build step is considered success. Anything other than 0 is considered failed. If during execution of a build step, the process exits with anything other than 0, it is considered failed. If there are multiple build steps (Free-style project jobs), the last Build Step's exit code marks the status of the whole run. Once again, any Build Step in between that exits with anything other than 0 will mark the build failed.
Post-build actions, such as Text-finder plugin can also change the status of the job run.
You are not supposed to be tinkering with job history files to change the status of previous jobs. If you need to change the job result, use post-build actions such as Text-finder plugin, but even then, it only allows to downgrade the result.
Here's a one liner to printing the commit SHA1 in a jenkins job using groovy post-build script:
println "git rev-parse HEAD".execute().text
You can save this to a variable or export it as a build parameter.
I have 3 bamboo stages: testing, staging and production. All of them extract the sources, compile and run tests. In previous version of Bamboo it continued the next stage if one failed (one of test failed f.e.). In the latest version it does not go to the next stage and stops build. How can i override this behaviour in order to continue build even if one stage failed?
Output:
simple 17-Sep-2013 17:56:12 Failing task since return code of [c:\dev\maven3\bin\mvn.bat --batch-mode -Djava.io.tmpdir=C:\Program Files\Bamboo\temp\CS-AND-JOB1 clean install -P envbuild -DbuildNumber=4] was 1 while expected 0
simple 17-Sep-2013 17:56:12 Parsing test results...
simple 17-Sep-2013 17:56:12 Finished task 'Maven 3.x'
simple 17-Sep-2013 17:56:12 Running post build plugin 'NCover Results Collector'
simple 17-Sep-2013 17:56:12 Running post build plugin 'Clover Results Collector'
simple 17-Sep-2013 17:56:12 Running post build plugin 'Artifact Copier'
simple 17-Sep-2013 17:56:12 Finalising the build...
simple 17-Sep-2013 17:56:12 Stopping timer.
simple 17-Sep-2013 17:56:12 Build CS-AND-JOB1-4 completed.
In short, you can't override this behaviour, this is how Bamboo (and other build tools) are designed to work.
What you should be doing is:
Build once and save the output as an artifact which can be used by later stages
Test your build output by retrieving the artifact from the first stage
Deploy to X environment
You shouldn't be deploying to an environment if any of the preceding steps have failed, the point of a failing stage is to indicate something is not right, you should either fix broken tests or exclude them.
I've contacted atlassian support and they confirm it's a bug - stages should be independent. They are investigating this problem.
I'm using Jenkins to build my projects on Maven 3.
There is ~15 jobs defined. They are running onCommit or by cron expression all day long (mostly once per hour). Some jobs are using Sonar (XXXDailyBuild not).
Sometime I'm facing error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:2.4.1:clean (default-clean) on project xxx: Failed to clean project: Failed to delete E:\CI\data\jobs\XXXDailyBuild\workspace\XXX\xxx\target\surefire\surefirebooter8004371362793469171.jar -> [Help 1]
It is caused by locked Jenkins workspace by active java process of surefirebooter8004371362793469171.jar
Jenkins job runs with 'Execute concurrent builds if necessary' disabled.
Any other job/process do not use 'XXXDailyBuild' workspace.
I'm trying to figure out what's going on.
Is there any way to dump running 'surefirebooter8004371362793469171.jar' process to analyze their heap?
Problem has been investigated:
Our application runs JUnit tests by surefirebooter maven plugin jar
Every tests need fresh models state
During models initialization old models state are disposed and fresh are initialized
Some models starts threads ie. Directory Watcher
The root PROBLEM is:
1. when some test fails in step 3. old models state aren't disposed
and this way some threads aren't stopped (duplicated on every test fail)
It was easy to check it using jvisualvm tool.
Finally, after maven test run process stays active forever.
Hope this analysis help someone!
Don't know the root cause and resolution. However, you can kill the java.exe from Task Manager (in Windows). This java.exe holds a lock on surefirebooter.jar file. Killing java.exe will Release that lock and you will be able to run the Maven Build.