We have recently switched from CruiseControl.Net to Jenkins for managing our builds. With CCNET it would trigger a new build X minutes after the last one completed, but with Jenkins it is constantly dropping builds in the queue, not allowing any time in between the two. We'd prefer the CCNET method.
I don't see how this can be done with the Scheduler Trigger, it seems to be all date time based.
I don't see any setting to prevent Queueing another build where the build is currently running.
I don't see a trigger that would allow for timing based off last run.
How could I manage this?
Jenkins lets you set a quiet period between builds, which can be set at the system level and overridden at the job level. Here's the help text from Jenkins:
If set, a newly scheduled build waits for this many seconds before actually being built. This is useful for:
Collapsing multiple CVS change notification e-mails into one (some CVS changelog e-mail generation scripts generate multiple e-mails in quick succession when a commit spans across directories).
If your coding style is such that you commit one logical change in a few cvs/svn operations, then setting a longer quiet period would prevent Jenkins from building it prematurely and reporting a failure.
Throttling builds. If your Jenkins installation is too busy with too many builds, setting a longer quiet period can reduce the number of builds.
If not explicitly set at project-level, the system-wide default value is used.
And here is a more detailed discussion.
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've noticed that there seems to be a build queue limit of one in Jenkins. When I trigger a lot of builds it seems to only place a max of one build in the build queue. Is there a way to remove this limit so there can be more then one build in the build queue?
This is intended behaviour:
Normally, your jobs will depend on some input (from SCM, or from some upstream jobs)
If your slave capacity is too low to catch up with each and every build, then you'd normally want to test/build/... only the very latest "item".
This is the default behaviour. Without that, there'd be a risk that the build queue grows indefinitely.
On top of that, Jenkins does not track the properties of normal build requests -- they all look the same, and Jenkins can not (for example) separate different SCM states that existed at different triggering times.
This is however exactly the point that gives you a workaround: parameterize your jobs, and then use for example the Trigger parameterized build on other projects post-build action to trigger those. Then Jenkins will queue each build request individually -- and inside your job, you can use the parameter to find out what exactly has to be done.
Jenkins will squash queued parameterized builds that have identical parameter values (thanks to user "atline" for checking).
Using Jenkins, I am running 2 builds (Linux+Windows) and one Doxygen job
At the moment, I am using 3 separate SCM polling triggers pointing to the same source code
How can I use a single trigger for all three jobs provided that I still want to get separate statuses
For the record; the underlying SCM is Git
Off the top of my head, some solutions which might do what you are looking for:
Instead of setting an SCM trigger, use a post-receive hook in your repository, which can send a signal for Jenkins that there are new changes (see: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-Pushnotificationfromrepository). This way Jenkins doesn't have to constantly poll the repository (multiple times for the different jobs), and the trigger would be faster, since there is no waiting for the next polling, but when there is a push, a build will be started.
Use an extra job, that would do nothing else, just have the SCM polling trigger, and start all three original jobs (without waiting for any of them to finish).
If the configuration is similar for all three jobs, you could consider creating a single project with a matrix configuration. Roughly what it does, is that you could have a variable for the build type, with values like linux, windows, doxygen. When the job is triggered, it would start multiple builds with all the possible values - of course you would have to set up the job in a way that the current parameter changes the build process according to what needs to be done. Actually I haven't had to use a matrix configuration yet, so my example may be not the best, but you can probably find lots of examples on the Jenkins wiki, if you think this is a good direction.
My fairly-large project uses gated builds, with a heavily-customized process template (XAML). For reasons beyond the scope of this question, our process has a single SharedResourceScope, so multiple builds don't run in parallel (I know you're supposed to do that with an Agent scope, but we switch agents in the middle, so wrapped everything with the SharedResourceScope).
Now, if there are several check-ins in queue, all of them go into "In Progress" state, and all but one wait on the SharedResourceScope. This means that:
People can't know which build is actually running
Even if I set a new queued check-in to be high-priority, it can't overtake all those who are in progress and waiting on SharedResourceScope, so the whole priority setting has little meaning.
I've experimented using DefaultProcessTemplate.XAML, and I see that usually only one build is In Progress (though Occasionally I see 2 builds).
Questions:
When exactly does a build start, and therefore goes into "In progress" mode? What prevents all builds from starting immediately, and blocking on AgentScope / SharedResourceScope?
Is there something I can author in my XAML to prevent all builds to go in progress?
A build starts when the build controller has capacity to start a new build. Since builds can use 0 to n agents, the controller doesn't wait to get an agent before the build starts. The controller determines its capacity based on the "Maximum number of concurrent builds" setting on the controller properties (in code: MaxConcurrentBuilds).
Default setting: "Default to number of agents".
No way in XAML to control this behavior.
Also, there's a bug in TFS2010 regarding this, hotfix: KB2567437
Using TFS Build Extensions, you get a number of activities with which you can administer agent control through the process: QueryBuildAgentStatus, IsBuildRunning, SetBuildAgentStatus to name a few that could be useful to you. They're fairly undocumented as of now, so you'll have to experiment to get them running. But there is a help file included in the package that is useful.
As for the "In Progress" mode, I've noticed that this is the status even if a build is waiting for a free agent; check the log of such a build and you'll see. This is quite confusing, and I hope that MS will add a "Queued (but not started)" mode.