How does travis-ci.org throttle builds?

Question

My company is using travis-ci.org (the free version for open source software) to automatically build pull requests to our repository on github. We have about 20 people submitting Pull Requests to the same repo throughout the day and each of these gets built in a matrix that includes two Build Jobs per Build. We often notice that it takes a number of minutes—and sometimes hours—for a build to start once it's been sent to travis. (Symptom: the build appears on travis but the timer doesn't start and there's no console output for a while.)

I assume this happens because the travis-ci.org is either backed up or throttles builds. First of all

Does travis intentionally throttle/rate-limit builds?

If so, how are builds throttled?

Per login? (i.e. per github user/organization, etc.)
Per repo?

Are builds throttled

Per "Build"?
Per "Build Job"?

Knowing this will let us optimize our build time-to-finish within the constraints travis-ci.org has set (which is hopefully aligned with playing nice as a free user).

Not really, I suppose I could use the word "queued" instead of throttled, but that's kind of part of the question—is travis intentionally throttling builds processes if we run too many at once (20 people submitting PRs throughout the day to the same repo)? I can update the question — Danny Roberts, Apr 13 '15 at 22:39
Is this build open source? I have never had travis take hours to build. — Jared Burrows, Apr 13 '15 at 22:52
Yes, this build is open source. It usually doesn't take even close to an hour, but when there's a lot of activity on our end 10s of minutes isn't uncommon just to get the build _started_ — Danny Roberts, Apr 14 '15 at 15:55
Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/75219/discussion-between-danny-roberts-and-jared-burrows). — Danny Roberts, Apr 14 '15 at 17:09

MattyB · Accepted Answer · 2015-04-20T15:46:48.960

If you check out the travis-ci status page (http://www.traviscistatus.com/) you'll notice that the "Active Linux Builds for Open Source projects" periodically maxes out. Based on how the travis private build system works (a single queue for all "Build Jobs" with no more than x running at a time), I suspect they have a single queue for all open source Build Jobs.

You can split up your build in to multiple jobs, each of which would finish faster. When Travis is under light use they would run in parallel and your build will return sooner, but when Travis is running lots of other builds yours may only run sequentially.

Looking at the .travis.yml in the repo you posted, you may notice good performance increases by adding apt and pip caching (http://docs.travis-ci.com/user/caching/). You should also consider switching to Travis' new container-based infrastructure (http://docs.travis-ci.com/user/workers/container-based-infrastructure/). That will only work however if you're able to replace the sudo apt-get commands in your build.

score 17 · Answer 2 · answered Jan 15 '16 at 10:52

Travis-CI currently provides five concurrent builds for open source projects, and this is counted against all repositories per GitHub login or organization, as the Apache Software Foundation discovered. Travis counts each "build job", across all projects and pull requests, towards this limit on concurrent builds.

score 4 · Answer 3 · answered Apr 20 '15 at 10:07

On Travis CI, all builds are queued, independently of your login or repository.

Also, if you have a look on the Travis CI status history (here http://www.traviscistatus.com/history), you will see that they noticed and investigated the issue you described on April 7th and April 8th. They also made an update of their Build environment on April 9th (http://docs.travis-ci.com/user/build-environment-updates/2015-04-09/). During the update the queue to process is growing and has to be processed later. This combination of things is probably the origin of the long delays you experienced.

I hope this will help you.

Jon Doe · Answer 4 · 2015-04-20T13:50:18.863

I use Travis for personal use and I have very few builds per day. I have often noticed a few minute delay before the build starts so that is probably normal. After a little research, I was not able to find very good numbers about Travis limits, but they definitely have some (source). This is a GitHub issue asking if they can limit builds per project so they do not hit their user/company limit as quickly. This means there is some limit enforced. The free version is described as "Fair Use" so I am not exactly sure what that means. If your builds are running slow I would look into speeding up the build so you get the most out of them before you hit your limit.

Sorry, I can not offer the actual numbers, but you should do your best to optimise the builds as it is. I am guessing they may not have any hard limits because they are probably still growing and changing what their systems can handle.

Some numbers I found:

Time limits http://docs.travis-ci.com/user/build-configuration/#Job-Timeouts
Plans and features https://travis-ci.com/plans

I will contine to look for the limit numbers and update my answer if/when I fine them.

How does travis-ci.org throttle builds?

4 Answers4