I came across /quietDown URL jenkinsQuietDown to pause a Jenkins Instance. I want to know if it can be used to only pause a job without impacting other running jobs on the instance.
I want to pause a particular job on failure, and restart from the top of the queue after resolution. This is to maintain order of execution of the job for different parameters.
The jenkinsQuietDown command work on jenkins level, not on job level.
quietDown: Put Jenkins in a Quiet mode, in preparation for a restart. In that mode Jenkins don’t start any build
Related
We are moving over our build system from Hudson to Jenkins and also to declarative pipelines in SCM. Alas, it looks like there are some hiccups. In Hudson, when a job was scheduled and waiting in the queue, no new jobs were scheduled for that project, which makes all the sense. In Jenkins, however, I observe there are e.g. 5 instances of a job started at the same time, triggered by various upstream or SCM change events. They have all even kind of started, one of them is actually running on the build node and the rest are waiting in "Waiting for next available executor on (build node)". When the build node becomes available, they all dutifully start running in turn and all dutifully run through, most of them without no purpose at all as there are no more changes, and this all takes a huge amount of time.
The declarative pipeline script in SCM starts with the node declaration:
pipeline {
agent {
label 'BuildWin6'
}
...
I guess the actual problem is that Jenkins starts to run these jobs even though the specified build node is busy. Maybe it thinks I might have changed the Jenkinsfile in the SCM and specified another build node to run the thing on? Anyway, how to avoid this? This is probably something obvious as googling does not reveal any similar complaints.
For the record, answering myself. It looks like the best solution is to define another trigger job which is triggered itself by SCM changes. It should do nothing else, only checks out the needed svn repos (with depthOption: 'empty' for space and speed). The job needs to be bound to run on the same agent than the main job.
The main job is triggered only by the first job, not by SCM changes. Now if the main job is building for an hour, and there are 10 svn commits during that time, Jenkins will schedule 10 trigger job builds to run. They are all waiting in the queue as the agent is busy. When the agent becomes available, they all run quickly through and trigger the main job. The main job is triggered only once, for that one must ensure its grace/quiet period is larger than the trigger job run time.
I want to upgrade my jenkins master without aborting or waiting for long running jobs to finish on slaves. Is there a plugin available that provides this feature?
We have several build jobs running regression and integration tests which take hours to run. Often, at least one of those jobs is running, making it hard to restart jenkins after updates. I know, that it is poosible to block the queue. We tried this, but it hinders more than it helps.
What we are looking for is a plugin, that runs jobs on slaves, caches the output as soon as the connection to the master is interrupted and sends the remaining output to the master when the master is up again. Does anybody know a plugin providing this feature.
I have a jenkins job that runs a bash script.
In the bash script I perform effectively two actions, something like
java ApplicationA &
PID_A=$!
java ApplicationB
kill $PID_A
but if the job is manually aborted, the ApplicationA remains alive (as can be seen with a ps -ef on the node machine). I cannot use trapping and so on, because that won't work if jenkins sends a 9 signal (trapping doesn't work for 9).
It would be ideal if this job could be configured to simply kill all processes that it spawns, how can I do that?
Actually, by default, Jenkins has a feature called ProcessTreeKiller which is responsible to make sure there are no processes left running after the job execution.
The link above explain how to disable that feature. Are you sure you don't have that disabled by mistake somehow?
Edit:
Following the comments by the author, based on the information about disabling ProcessTreeKiller, to achieve the inverse one must set the environment variable BUILD_ID to the build id of Jenkins job. This way, when ProcessTreeKiller looks through the running processes to kill, it will find this as well
export BUILD_ID=$BUILD_ID
You can also use the Build Result Trigger plugin, configure a second job to clean up your applications, and configure it to monitor the first job for ABORTED state as a trigger.
Our Jenkins performs massive integration tests. The longer the jenkins is running, the longer the tests need. Thus we restart the Jenkins server every night via cronjob. Meanwhile the build queue is too long to be finished and the currently running job is canceled and a fail. That's ugly. I found the Safe Restart Plugin, but that waits for empty build queues. Ideally I would have a job which could be priorized to also reboot at every wanted time during the day. This job needs to perform the reboot as the safe restart plugin would do if no jobs where left.
Is there an elegant way to temporarily prevent Jenkins from executing any further builds in a defined time frame (say e.g. daily between 6am and 7am)?
Rather than stopping Jenkins, you can put it into "Quiet Down" mode, which prevents any new builds from taking place.
You can enable this via the URLs /quietDown and /cancelQuietDown, or via the CLI commands [cancel-]quiet-down.
Depening on what you want to achieve exactly you can probably use the Exclusive Execution Plugin. This plugin allows you to schedule a job which will block execution of all other jobs by putting Jenkins in shutdown mode (which is canceled when the job is done). You can make this job start at 6am and make ik run a simple ant script which sleeps for an hour.
However, if you are trying to use that window to e.g. run a backup you could actually run your backup from within that job, which will make 100% sure your backup won't start until all
running jobs are completed and it will make Jenkins available again as soon as the backup is done.
Alternatively you could consider using cron or the windows scheduler (depending on your OS) to stop Jenkins completely at 6am and restart it at 7am.