Problem :
A certain task often crashes the slave, which then should reboot (sometimes it doesn't). If the reboot fails, it may take a week until someone reboots the computer. Then the build which failed couldn't archive the artifacts.
Idea to solve it (if there is a better one please tell me) :
To have a task always launch after this one which checks if the artifacts failed to be made (I have a way to check it), and then wait forever until the slave becomes available again, to archive the artifacts.
I know it's possible to do such for every job, but I cannot find how to do it for a specific job.
The best solution is to actually fix what crashes your server.
But for now you can add another job:
In Jenkins create a "New Item".
Make this a freestyle project.
In the "Build Trigger" section, select "Build after other projects are built".
Here you select the other job that causes the slave to crash.
Afterwards add you monitoring-and-restart-script as a build step.
Related
For internal reasons, one of my jobs is able to run concurrently, but new builds abort themselves if another build is already running (disabling concurrency doesn't help, since I don't want new jobs to be scheduled for execution once the current build is done).
However, this behaviour is detrimental to the job status preview (the colored ball next to the job name when inside the job's parent folder). It often shows the status as "aborted", which is undesirable - I want to view the latest running build as the source of the job status.
I tried deleting aborted builds from within their own execution, but that's unfortunately neither trivial nor stable, and thus not suitable for this situation. I could probably get a workaround running that deletes them from a separate job, but that's not ideal either.
Anyway, I'm now hoping that I can just tell Jenkins to ignore "aborted" builds in the calculation of the job preview. Unfortunately, I wasn't able to find a setting or plugin that allows me to do this.
Is this possible at all? Or do I need to find another way?
Would something like this help?
https://plugins.jenkins.io/build-blocker-plugin/
I haven't used it myself but it supports blocking builds completely if a build is already running.
Doesn't anyone know of a Jenkins plugin that ensures that when a job is re-run, it runs on a different node to the previous one? Problem is not all developers have permission to take problematic nodes offline, so they end up not being able to build their branch because Jenkins keeps trying to re-run on the same one.
Assuming all your nodes have same configuration; You can group them under same Label;
To re-run the build you can try -
https://wiki.jenkins.io/display/JENKINS/Naginator+Plugin
You might want to configure node to get offline when idle for certain time.
And aim to re-trigger the build after that time; There is a fair chance the build would run on another Node.
But the question is, what are the chances of build getting successful if nothing has changed. Re-trigger without changes doesn't give successful build unless there is a temporary issue.
I am publishing build results to Sonarqube, with jenkins.
Each commit on git is triggering a jenkins build.
My problem is that build duration is not deterministic so build #2 can finish before build #1.
Consequently, results are published to Sonar in wrong order and differential view shows wrong results.
For example, if i corrected a unit test in build #2, results of build #1 will tell me that test is failing again.
Build result version is setted and it should be used to order builds instead of publication date.
Is there any way to do it?
Thank you.
The SonarQube platform is going to process the analysis reports in the order it receives them. It has no way of knowing anything about your Jenkins build number.
Your best bet is to enable the Throttle Concurrent Builds option to make sure that each new job waits its turn. That's the only way to ensure the order you expect.
I'm trying to tweak some options in my jenkins configuration, which is causing many builds to fail. I'd prefer to not keep these failures around in the build history, since they're not technically failures of the repository. In the past, I've just deleted the build after looking at the log, but this is a little tedious.
Is there a way to start a build with an option to not record the result of the build permanently?
Perhaps there's a URL that can be used to trigger a debugging build, somethign like:
JENKINS_URL/job/JOBNAME/build?DEBUGGING
You can set the "discard old builds" option in your job to only keep 1 build. If you have older builds you want to keep, you can give them the "keep this build forever" property. If you have a large number of jobs to work with, you can use the Configuration Slicing plugin to modify the Max # of builds to keep.
I checked in some code and my build was added to the build queue. I can't go home until the build passes.
There is nobody in front of me, but it's been well over half an hour since my checkin and my build hasn't started (plus it's a half an hour to build the 49 large projects against the build environment). I've been at work since morning and just want to go home before midnight (it's past 8:30 already). My checkin's just sitting their in queue, not being fired off.
How do I force the build to start in an empty build machine if there is nobody in front of me in queue and nothing else going on?
edit: This is what I get for breaking my own rule of never checking in after 3pm unless it's a mandate.
Open the Team Explorer pane and navigate to your team project. Expand the 'Builds' node and find the build definition that you need to build. You should then be able to right-click it an choose 'Queue new build..'. (This does require a separate permission, and you may not have that permission).
This will then bring up the confirmation dialog where you can specify the shelveset to build (if its a gated build).
If the Builds screen shows that there are queued builds, and none running - it could be that there are no available Build Agents or they are marked offline. See Manage Your Build System for more information about how to check the status of your build agents.