CODEWITHSUNDEEP
travis-ci
Danny Roberts
Danny Roberts

Reputation: 3572

How does travis-ci.org throttle builds?

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

If so, how are builds throttled?

Are builds throttled

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).

Upvotes: 36

Views: 9059

Answers (4)

shoyer
shoyer

Reputation: 9633

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.

Upvotes: 17

MattyB
MattyB

Reputation: 952

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.

Upvotes: 27

Christian
Christian

Reputation: 2200

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:

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

Upvotes: 2

Guillaume Pascal
Guillaume Pascal

Reputation: 845

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.

Upvotes: 4

Related Questions