LINUX.ORG.RU

Travis CI и лимит по времени

 , ,


0

1

У Travis CI есть ограничение по времени (50 минут для некоммерческих проектов, 120 для коммерческих). Для большинства поделок этого времени выше крыши, но не в том случае, если я хочу собирать тулчейн (да ещё и в один поток).
Если обратиться к документации, понятно, что ограничение по времени можно обойти:

It is very common for test suites or build scripts to hang. Travis CI has specific time limits for each job, and will stop the build and add an error message to the build log in the following situations:

  • A job produces no log output for 10 minutes
  • A job on travis-ci.org takes longer than 50 minutes
  • A job on travis-ci.com takes longer than 120 minutes

Some common reasons why builds might hang:

  • Waiting for keyboard input or other kind of human interaction
  • Concurrency issues (deadlocks, livelocks and so on)
  • Installation of native extensions that take very long time to compile

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.

Правильно я понимаю, что если поставить десяток команд сборки подряд и запустить фоновый процесс, который будет раз в полчаса убивать один процесс сборки, то такими проциями можно компилять на трависе, сколько душа пожелает (каждая следующая команда после убитой продолжает с того, на чём остановилась предыдущая, а те, которые были запущены после удачного окончания сборки, сразу же завершаются, так как им нечего делать). Или я не прав?

★★★★★

Лимит на одну джобу 50 минут, а в билд матрице можно до 200 джоб. Ну они еще рекомендуют на мелкие скрипты делить.

Implementing Complex Build Steps #

If you have a complex build environment that is hard to configure in the .travis.yml, consider moving the steps into a separate shell script. The script can be a part of your repository and can easily be called from the .travis.yml.

Samsky
()

Правильно я понимаю, что если поставить десяток команд сборки подряд и запустить фоновый процесс, который будет раз в полчаса убивать один процесс сборки, то такими проциями можно компилять на трависе, сколько душа пожелает

Нет конечно, каждая джоба запускается на чистой виртуалке или контейнере

anonymous
()
Ответ на: комментарий от slaykovsky

It is important to note that jobs do not share storage, as each job runs in a fresh VM or container. If your jobs need to share files (e.g., using build artifacts from the “Test” stage for deployment in the subsequent “Deploy” stage), you need to use an external storage mechanism such as S3 and a remote scp server.

anonymous
()
Ответ на: комментарий от anonymous

Значит, я просто не разобрался с терминологией, сорри. Я почему-то подумал, что джоба — это каждая строчка секции «script» в .travis.yml. А билд — это каждый запуск этой чистой виртуалки.

CYB3R ★★★★★
() автор топика
Последнее исправление: CYB3R (всего исправлений: 1)

Ты либо тулчейн куда-нибудь загрузи, чтобы его лишний раз не собирать, либо попробуй один раз собрать с включенным ccache, если часто изменения делаешь.

a1batross ★★★★★
()
Ответ на: комментарий от a1batross

Так там и сама сборка тулчейна может занять приличное время...

// Сам думаю над тем, чтобы собирать свой проект под макось через травис, ибо мак не всегда доступен, но хочется статически линковать к нему Qt, а это значит - собирать...

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Можно собрать только тулчейн или только Qt с включенным ccache, потом включить в сборку всё остальное. ccache у меня ускорил сборку раза в три.

a1batross ★★★★★
()
Ответ на: комментарий от anonymous

Проблема только в том, что это не тулчейн, нужный для сборки проекта, а сам проект — это тулчейн.

CYB3R ★★★★★
() автор топика
Ответ на: комментарий от hobbit

Сам думаю над тем, чтобы собирать свой проект под макось через травис, ибо мак не всегда доступен, но хочется статически линковать к нему Qt, а это значит - собирать...

Но зачем статически линковать? В macOS ведь имеются прекрасные DMG-пакеты, позволяющие обходить Dependency Hell, да и вообще сборка софта под macOS на мой взгляд куда удобнее, чем под GNU/Linux.

Раз:

language: cpp

matrix:
  include:
    - os: osx
      compiler: clang
      osx_image: xcode7.3

script:
  - PATH="$(brew --prefix qt)/bin:$PATH" qmake CONFIG+=release MyApp.pro
  - make > /dev/null
  - PATH="$(brew --prefix qt)/bin:$PATH" macdeployqt MyApp-Qt.app -always-overwrite -dmg
  - curl --upload-file ./MyApp-Qt.dmg https://transfer.sh/MyApp-Qt.dmg

before_install:
  - eval "${MATRIX_EVAL}"

install:
  - brew update > /dev/null
  - brew install qt5
  - brew link qt5 --force
  - brew install boost@1.57
  - brew install qrencode
  - brew install miniupnpc
  - brew install berkeley-db

И у тебя готовый аккуратненький пакетик твоего приложения со всеми нужными зависимостями вроде boost'а и прочих библиотек.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Никогда не видел, что бы кто-то забирал результаты работы Travis. Но вообще правильно, что добру-то пропадать?

CYB3R ★★★★★
() автор топика
Ответ на: комментарий от CYB3R

Никогда не видел, что бы кто-то забирал результаты работы Travis.

Ну вообще, у них в документации есть целый раздел на эту тему.

Жаль, что версии OS X старше 10.10 не поддерживаются.

hobbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.