My Jenkins build hangs between build and post-build steps.
The console output shows there is a 6-minute wait (but I've seen waits of up to one hour):
10:53:26 BUILD FAILED in 1m 7s
10:53:26 4 actionable tasks: 4 executed
10:53:26 Build step 'Invoke Gradle script' changed build result to FAILURE
10:53:26 Build step 'Invoke Gradle script' marked build as failure
11:09:29 [CucumberReport] Using Cucumber Reports version 4.9.0
I found this and this questions that have similar issues, and they say the solution is setting -DSoftKillWaitSeconds=0 in jenkins.xml.
However, I need a way to set the option for particular jobs only, without messing with global Jenkins settings (I wouldn't want to mess with other projects).
EDIT:
When I manually abort the job, before the [CucumberReport] step, Cucumber reports are still generated.
I also checked Abort the build if it's stuck checkbox in Build Environment options, with Time-out strategy set to No Activity (Timeout seconds = 2).
When I build the project with these settings, the build will fail with "Aborted after 0 seconds" shown in Build History, as before, but the console output will be the same. (Nothing changes, Cucumber Reports will be generated but after a certain timeout).
It is not possible to select a job-specific value for SoftKillWaitSeconds (the value is derived from the Jenkins core at a point where the job name is not known).
My recommendation is to fix the abort handling in your job itself, so it will not depend on a "soft kill timeout". If you're running on a Unix-ish system, you can ensure this by running your job in a new process group (set -m in bash) and (for example) setting up a proper exit trap.
We are using the Build-timeout plugin to kill stuck jobs with timeout strategy set to No Activity or Absolute. For me, this is a good approach when you are using freestyle projects.
The reason why your build is "Aborted after 0 seconds" is that most likely there are unfinished child processes.
From documentation:
Because Java only allows threads to be interrupted at a set of fixed
locations, depending on how a build hangs, the abort operation might
not take effect. For example,
if Jenkins is waiting for child processes to complete, it can abort
right away.
if Jenkins is stuck in an infinite loop, it can never be
aborted.
if Jenkins is doing a network or file I/O within the Java VM
(such as lengthy file copy or SVN update), it cannot be aborted.
You could try the absolute timeout strategy. You can define a global variable, so that you do not repeat the timeout value in jobs:
Go to "Manage Jenkins" > "Configure System".
Check "Environment variables" in "Global properties".
Add an environment variable name="GLOBAL_TIMEOUT_MINUTES" value="20".
Go to a configuration page of a project.
Check "Abort the build if it's stuck" in "Build Environment".
Select "Absolute" for "Time-out strategy". Of course, also applicable to other strategies.
Set "${GLOBAL_TIMEOUT_MINUTES}" for "Timeout".
Set timeout action "Abort the build".
If this is not working, you could try to look in the logs https://your-jenkins-server/log or in a thread dump.
The hanging may be caused by new/old version of a plugin. Try to find what are the unfinished child processes. Try to disable post-build actions one by one to find the one that may be the cause of the issue.
You can see https://superuser.com/questions/1401879/debugging-what-happens-when-a-jenkins-build-unexpectedly-pauses-or-hangs
Related
I'm using TeamCity plugin with IntelliJ and working with the following workflow:
https://confluence.jetbrains.com/display/TCD10/Pre-Tested+%28Delayed%29+Commit
My concern is if this process can be automated in a manner that the last step which says "commit my local patch if the build succeeded" and the step will be done on the TeamCity side and not on my local laptop.
Can I add some extra step in the build that says "If the build succeeded commit this patch to SVN" (from the TeamCity server)
It just feels like the wrong way that the server needs to keep a connection with my laptop until the end of the build.
It causes a lot of commit failures due to network glitches, authentication failures, files with other revision etc.
This set up is not possible, as TeamCity is not aware of your local version control credentials and settings, that will be used during commit from the IDE.
Gradle seem to be really slow for me and I have no idea why.
Whenever I run a build it takes like 30 seconds for me, according to the output 25 seconds of those it's doing nothing.
Building like this:
gradlew build --parallel --offline
This is happening to me now with Kotlin, it was the same when I was using Java only, incremental builds don't seem to do anything either
EDIT: I have the gradle daemon enabled
Every subsequent build right at the start takes as long or longer than starting the daemon apparently doing nothing
This is my Project: https://github.com/forsakenharmony/GameProt
I recommend starting with some measurement:
gradlew build --profile
Open up /report/profile in a web browser and see what it's doing.
It sounds to me like your project is taking a long time to configure. Do you have a large project or many projects in your build? Are you using a bunch of plugins?
The easy way to reduce configuration time is to configure fewer things. Remove plugins that you only use rarely. Try out the #Incubating --configure-on-demand option.
Come back after you've confirmed via profiling for further help.
You can try enabling gradle daemon.
That way gradle won't have to load from scratch every time you start a build. Instead, it will run in background waiting for a build to start.
org.gradle.daemon=true
in «USER_HOME»/.gradle/gradle.properties
I know it may look like a duplicate of How to disable Gradle daemon in IntelliJ Idea?, but I don't want to completely disable gradle daemon. I just want to use only one daemon, not many of them.
The problem I have is that to successfully run some gradle tasks I have to give about 2GB RAM to gradle. And my system only had 8GB of memory.
The problem is that when I perform certain actions (I think it's "refresh gradle projects", there are 2 of them) - I sometiems get 2 or more gradle daemons running. Each consuming 2GB of memory.
Is it possible to use only one daemon or somehow automatically stop those extra daemons?
You can stop all currently running daemons with gradlew --stop. New deamons are only created if necessary. If e. g. a different Java version is used or different daemon arguments are needed and so on. You could maybe look with Sysinternals ProcessExplorer and compare the two processes to find where they differ to find a reason why two are created.
I'm looking for an IntelliJ IDEA plugin that would run my tests each time I change my code. I looked for such a solution and I found:
Infinitest, which works, but is inconvenient because I need to add the facet to each module, and it opens a new tool window for each module (which means 15 tool windows for me).
Fireworks - didn't work for me, maybe it just doesn't work with IDEA 14 (in its repo I can see that last changes were made in 2009). IntelliJ also reports that it throws exceptions.
There are lots of ways I could run all my tests (including writing a simple script for this), but I'm looking for a tool that would be smart enough to rerun failed tests first, and that would understand module dependencies (so after a change in some module it would run only tests of dependent modules).
I prefer free options, but if there's something paid for a reasonable price, I would accept it as well.
IntelliJ now actually has a Toggle auto-testin the run dialog. Just run a run-configuration and then select Toggle auto-testin the run dialog.
It's not as intelligent as you would have hoped. It just reruns when it detects changes.
I know this is a 3-year-old question but I think it will help people who face the similar problem in future. So I found out a way to enable SBT style auto test execution in IntelliJ studio.
We need to do 2 things to enable auto test execution.
Enabling auto project build - This can be done in settings by going into File -> Settings -> Build, Execution... -> Compiler and selecting "Build Project automatically".
Enabling "Toggle auto-test" in run dialog box
This will start auto testing. Although this works fine, it takes time to build the project even when my project is tiny so for larger projects it will certainly take very long time to complete the build and execute tests.
Reference: Original article which explains these steps
If you are OK running tests which cover a single method chosen by you, you can try this plugin (it is continuos in the sense that you make changes to a method, then click on the method and the plugin will run all the unit tests automatically which cover that method): https://plugins.jetbrains.com/plugin/15063-unit-test-coverage-history-runner
You can use the Intellij Teamcity plugin. Teamcity is a paid product but there is a free version which gives you 20 projects and 3 agents for free .
It has a remote run feature using which you can send in unchecked code to run tests before committing.
It also has options to run failed tests first
Usage instructions for Remote Run
I have job A that is building after developers commit code (SCM change). I also have job B that should be run once a day (by cron) and it should use the artifact that results from execution of build A.
Is it possible to configure Hudson job B to run on cron and before it really executes it should trigger execution of job A?
Job A shouldn't know anything about job B.
Perhaps a better way to do what you want. Have Job A mark the files that Job B wants as Artifacts (preserves them between builds). Then have Job B on it's cron schedule and when it runs, it uses the Copy Artifact Plugin to retrieve the required files from Job A. Then Job B can do it's build operation.
If you have a maven project (which is also a good way to pass artifacts from one build to another), the M2-extra-steps jenkins plugin (now deprecated and integrated into the M2 plugin I think) allows you to do that:
As a pre-build step, add 'build another project', check 'lock until build is done' and that should do what you need.
If you do have a freestyle project - I'm not sure. If the equivalent does not exist you might be able to come up with something based on locks and latches.
All that said, why do you want to rebuild A before B if it hasn't changed since the last SCM commit?