Как работает дроссель traviscc.org?

Моя компания использует travis-ci.org(бесплатную версию для программного обеспечения с открытым исходным кодом), чтобы автоматически создавать запросы на загрузку в наш репозиторий на github. У нас около 20 человек, которые отправляют запросы Pull на один и тот же репо в течение дня, и каждый из них создается в матрице, которая включает в себя две сборки для каждой сборки. Мы часто замечаем, что требуется несколько минут, а иногда и часов, - чтобы сборка началась, как только она была отправлена на travis. (Симптом: сборка появляется на travis, но таймер не запускается, и на какое-то время нет выхода консоли.)

Я предполагаю, что это происходит, потому что travis-ci.org либо резервное копирование, либо дросселирование. Прежде всего

Предусматривается ли у Трэвиса намеренно дросселирование/ограничение скорости?

Если да, то как строятся дросселирование?

За вход? (например, для пользователя/организации github и т.д.).
За репо?

Строит дросселирование

Per "Build"?
Per "Build Job"

Знание этого позволит нам оптимизировать время сборки до конца в рамках ограничений, установленных travis-ci.org(который, мы надеемся, выровнен с хорошим поведением как свободный пользователь).

Ответ 1

Если вы посмотрите страницу статуса travis-ci (http://www.traviscistatus.com/), вы заметите, что "Active Linux Builds для Open Source проекты" периодически расширяются. Основываясь на том, как работает система private build travis (одна очередь для всех "Сборка заданий" с одновременным запуском не более x), я подозреваю, что у них есть одна очередь для всех open-source Build Jobs.

Вы можете разделить свою сборку на несколько заданий, каждая из которых завершится быстрее. Когда Travis находится под легким использованием, они будут работать параллельно, и ваша сборка вернется раньше, но когда Travis запускает много других сборок, ваш может запускаться только последовательно.

Глядя на .travis.yml в репо, который вы опубликовали, вы можете заметить, что хорошие показатели производительности увеличиваются путем добавления кэширования apt и pip (http://docs.travis-ci.com/user/caching/). Вы также должны рассмотреть возможность перехода на новую контейнерную инфраструктуру Travis (http://docs.travis-ci.com/user/workers/container-based-infrastructure/). Это будет работать, однако, если вы сможете заменить команды sudo apt-get в своей сборке.

Ответ 2

В настоящее время Travis-CI предоставляет пять параллельных сборок для проектов с открытым исходным кодом, и это учитывается во всех репозиториях для входа или организации GitHub, как открылся Apache Software Foundation. Тревис подсчитывает каждое "задание сборки" по всем проектам и тянет запросы к этому пределу при параллельных сборках.

Ответ 3

В Travis CI все сборки находятся в очереди, независимо от вашего логина или репозитория.

Кроме того, если вы посмотрите историю состояния Тревиса CI (здесь http://www.traviscistatus.com/history), вы увидите, что они заметили и исследовали вопрос, который вы описали 7 апреля и 8 апреля. Они также обновили среду сборки 9 апреля (http://docs.travis-ci.com/user/build-environment-updates/2015-04-09/). Во время обновления очередь на процесс растет и должна быть обработана позже. Эта комбинация вещей, вероятно, является источником длительных задержек, которые вы испытали.

Надеюсь, это поможет вам.

Ответ 4

Я использую Travis для личного использования, и у меня очень мало сборок в день. Я часто замечал за несколько минут до начала сборки, так что это, вероятно, нормально. После небольшого исследования я не смог найти очень хорошие цифры о границах Трэвиса, но у них определенно есть (источник). Это вопрос GitHub, который спрашивает, могут ли они ограничить сборку для каждого проекта, чтобы они не ударяли их лимит пользователя/компании как можно быстрее. Это означает, что существует определенный предел. Бесплатная версия называется "Справедливое использование", поэтому я не совсем уверен, что это значит. Если ваши сборки работают медленнее, я бы рассмотрел ускорение сборки, чтобы вы максимально использовали их, прежде чем достигнуть своего предела.

Извините, я не могу предложить фактические цифры, но вы должны сделать все возможное, чтобы оптимизировать сборки, как есть. Я предполагаю, что у них могут не быть жестких ограничений, потому что они, вероятно, все еще растут и меняют то, что могут обрабатывать их системы.

Некоторые числа, которые я нашел:

Ограничения по времени http://docs.travis-ci.com/user/build-configuration/#Job-Timeouts
Планы и функции https://travis-ci.com/plans

Я буду следить за номерами пределов и обновлять свой ответ, если/когда я их штраф.