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.
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.
I have a Jenkins Job that is running periodically (Every minute).
As so, I end up with thousands of logs that doesn't really matters to me and overload the space disk.
Is there a way to configure that job, in a way it will keep just the last 100 builds and delete the old ones?
I know this is possible manually, But I am looking for a way that I don't have to do it myself every time, I want the job, or another one to do it automatically.
You do not need to do that manually, you just configure the job to retain the # of builds to retain during creating the job. This again can be done when you create the job itself through a rest api, all you have to do is to set the appropriate values in the job's config.xml. You configure the job once and never have to worry, Jenkins automatically takes care of the clean-up.
Note
Once you configure the job, the next run will be over the threshold and trigger deleting the excess job logs.
Also, since LTS 2.204.6: Add globally configured build discarders that delete old builds not marked as "keep forever" even if there is no, or a less aggressive, per-project build discarder configured, executed periodically and after a build finishes
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.
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.
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.