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