Let's say i have repo which for each push (build) starts 4 jobs (diffrent environment/compilers etc.).
There is time limit for builds - 50min. Is it counted as sum of times of all builds (like in left panel), or is it independant for each job?
Example: 4 builds, each taking 20minute - will it timeout becouse it will be counter as 80min or will it be ok and count as 20min (time of longest job)?
The Travis CI documentation is pretty clear about this. A build consists of one or many jobs. The limit is enforced for each job:
There is no timeout for a build; a build will run as long as all the jobs do as long as each job does not timeout.
For example, the current timeout for a job on travis-ci.org is 50 minutes (and at least one line printed to stdout/stderr per 10 minutes).
Related
I have a job and it can run concurrently. The trick part here is that this job needs to have an interval to one another, at least for 30 seconds. So when Build1 runs, Build2 should wait for 30 seconds to start.
I already tried using the quiet period but it does not fit my needs (it only works when a job is not triggered by Build Now or Build With Parameters)
Is there a way for me to be able to do this kind of condition?
You can try enumerating other builds of this job and sleeping until all the other builds have been running above 30 seconds. See example code in this answer.
I am dealing with a build pipeline that has some very long wait times in between builds due to outside dependencies. I've found that you can indeed tell a build to sleep before it executes its build steps here. However, I was wondering if there is a limit to how long the sleep can last for. In some cases I'd like builds to wait for 24 hours between builds in the pipeline, inputting 24hrs as 86400 seconds is a little unsettling, but I suppose it's not that unreasonable.
There is no limit implicitly within Jenkins. It will bee limited by your infrastructure reliability and the like.
If you are using jenkins pipeline, ensure that the wait's do not occur whilst consuming an executor (inside a node block).
It may be better, (again if using pipeline) to use a timeout() block rather than a arbitrary sleep, so it resumes as soon as ready.
https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-timeout-code-enforce-time-limit
I have around three Jenkins slave that are configured to run the same job allowing only one concurrent run on each slave. Each of these slave is connected to an embedded hardware that we run the job on. The total duration of the job is around 2 hours. The first 1 hour 50 mins is just taken to compile and configure the slave and the last 10 mins is when the embedded device is used. So basically I was looking for something that I can lock on for the last 10 mins. This would allow us to run multiple concurrent builds on the same slave.
Locks and Latches locks are shared across nodes.
What I am looking for is a node specific lock
If you can separate the problematic section from the compilation process you can just create another job to handle the last 10 minutes and call it using Parameterized Trigger Plugin. This job will run one instance at a time and will act as a native blocker for the run. That way, you can configure concurrent executions and throttling (if needed) on the main job, and create a "gate" to the problematic section.
I have a job that kicks off on any commit. It takes 5-10 minutes to run.
But if (say) 4 or 5 git commits come back-to-back I don't want 4 or 5 jobs run - just one job for the last commit. So basically if there is a job of type "X" in the build queue I don't want another job of type "X" in the queue.
That should be the default behavior if you're using the SCM trigger, default job parameters, and don't check the 'Execute concurrent builds if necessary' option.
First job is going to queue and run immediately.
On source change, next job is going to queue and wait until first one is complete.
A third SCM change would detect job already in queue and not do anything.
When first job is done, next one will start - and will use whatever is in the SCM at the moment it starts (not the moment it was scheduled).
That behavior can be changed using parameters, concurrent builds, job throttling, etc. My knowledge there might also be outdated (Jenkins is evolving pretty fast).
On a side note: multiple builds are not necessarily a bad thing - they give you failure locality, which might allow you faster identification of the offending commit. It doesn't matter much for 10 minutes builds, but if your build grows larger than that it can be a problem (with a large team, you can have a LOT of commits in 30 minutes).
Basically you just want to check if there is a new commit every 5 or 10 minutes? You can do that inside the triggering configuration: monitor source control every X minutes (CRON syntax: */15 * * * * for every 15mins)
If you check every 15 minutes if a new commit happened and your jobs only takes 10 minutes to run, there is no chance you would have another execution pending (unless someone ask for a "manual" construction...).
To avoid the latter case, you may consider the Throttle Concurrent Builds plugin
we are running Jenkins with lots of jobs. At the moment these jobs are kind of grouped by using "master jobs". These do nothing but start all jobs of one group. But, if one of these master jobs runs, it starts around 10 other jobs at one time. Depending on the duration of these jobs and the number of build processores (at the moment 6) Jenkins is blocked for a longer time (up to an hour). The other thing is, that these jobs are not really suitable for such massive parallelization.
To solve this, I'm looking for a way (a plugin), that allows to group some jobs and start them parallel, but limit the build processors used for the jobs of this group to a fixed number (e.g. 2). So it would be possible to run a group of jobs that compile java projects and parallel another group of jobs that installs test databases.
I tried the Build flow plugin, but it's not really the right one: you must separate the jobs manually to the sub-groups that run parallel and if a job in one sub-group failes, the following jobs of this group are not started.
So, maybe someone knows a Jenkins plugin that fits better? Thanks a lot in advance!
Frank
Throttle Concurrent Builds Plugin
Create some category my-group.
Add all the jobs into this group.
Set Maximum Total Concurrent Builds and Maximum Concurrent Builds Per Node.