Пытаемся понять, что делает Travis CI и когда его следует использовать

Я новичок в Git, и я планирую внести свой вклад в какой-нибудь проект с открытым исходным кодом на GitHub после обнаружения в нем небольшой ошибки. После его разветвления и исправления ошибки я разработал запрос на перенос и заметил следующее:

Ошибка - сборка Travis CI не удалась.

Изучив детали, я обнаружил, что это было вызвано Could not find .travis.yml, что имело смысл, поскольку я не входил в Travis Cl и не добавил .travis.yml в репозиторий.

Я впервые слышу о Трэвисе и о том, что называется непрерывной интеграцией. И это звучит довольно круто, поэтому, чтобы узнать больше об этом, я поискал его в Википедии.

Travis CI - это размещенная распределенная служба непрерывной интеграции, используемая для создания и тестирования проектов, размещенных на GitHub. Travis CI автоматически определяет, когда была сделана фиксация и помещена в репозиторий GitHub, использующий Travis CI, и каждый раз, когда это происходит, он будет пытаться построить проект и запустить тесты . Это включает коммиты во все ветки, а не только в главную ветку.

Мое текущее понимание Travis CI состоит в том, что то, что он делает, автоматически подталкивает проект, git commit -am ".."и я не совсем понимаю его часть.

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

2. В нем говорится, что «Это включает коммиты для всех ветвей» - но что, если я не хочу коммитить во все ветки?

3. Ничего страшного, если я вообще не использую Travis Cl? При каких обстоятельствах лучше всего его использовать (или его нужно использовать)?

Самый простой способ объяснить Travis CI - это то, что он запускает тесты вашей программы каждый раз, когда вы делаете коммит на GitHub (это можно настроить разными способами, и вы всегда можете отключить сборки в некоторых ветках). Дело в том, что вы часто можете очень быстро обнаружить, что ваша фиксация что-то сломала, и исправить это до того, как это станет проблемой. Я бы рекомендовал запускать Travis CI в каждом репозитории GitHub, в котором у вас есть модульные тесты и где используется язык программирования, поддерживаемый Travis CI. Поскольку настроить Travis CI очень просто, я обычно не вижу веских причин не использовать его, если вам все равно, проходят ли вы тесты в вашей программе или нет. Не стесняйтесь оставлять комментарии, если у вас есть еще вопросы. Вы можете узнать больше о Travis CI здесь .

Поскольку вы уже узнали, что такое Travis-CI, я бы прямо указал на ваши вопросы.

Какие тесты он будет запускать, собрав проект и запустив тесты? И как он собирается «строить» проект? (например, скомпилировать его в двоичный?)

В .travis.ymlфайле a вы указываете свою ОС, язык программирования, ветку репо, имя файла проекта и другие детали. Читая этот файл, Travis-CI будет использовать определенные компиляторы, установленные на их сервере, для компиляции нашего кода. Вероятно, у них будет такой же механизм, как у нас на Github. Впервые они могут извлечь код [если мы указали определенные ветви, они могут извлечь код только из этих ветвей]. Кроме того, мы прошли аутентификацию, чтобы использовать нашу учетную запись в Travis-CI, всякий раз, когда мы делаем коммит, на сервере Travis-CI должно срабатывать какое-то уведомление, поэтому оно будет распознано как фиксация и начнет компилироваться.

В нем говорится, что «Это включает коммиты для всех ветвей» - но что, если я не хочу коммитить во все ветки?

Вы можете указать разные ветки или masterветку. И он должен компилировать только определенные ветки, указанные в .travis.ymlфайле.

Ничего страшного, если я вообще не использую Travis Cl? При каких обстоятельствах лучше всего его использовать (или его нужно использовать)?

Да все в порядке. Не так уж и важно. Но каких преимуществ вам будет не хватать, если вы не будете использовать этот простой в интеграции движок с вашим репо? Каждый раз, когда вы делаете коммит, возможно, что он что-то упустит и не сможет скомпилировать из-за кода. Как ты узнаешь? Таким образом, вам следует использовать Travis-CI.

_{Я написал в блоге пост , который вы можете прочитать , чтобы знать, что Travis-CI, Непрерывные Интеграции и как связаны Travis-CI с вашим Github Repo. Я написал это для репозитория Swift.}

Я думаю, что могу ответить на ваш вопрос, так как в данный момент изучаю Travis CI. Первая проблема, с которой вы столкнулись в первую очередь, заключается в том, что проект, в который вы участвуете, использует Travis CI для тестирования и сборки проекта. Если бы в проекте не использовался Travis CI, вы бы не столкнулись с такой ошибкой.

Решение - зайти на сайт Travis CI и узнать, как он работает и как это повлияло на проект, над которым вы работаете. Это поможет вам понять, что не так в вашем коде и как это исправить.

Чтобы ответить на первый вопрос о построении проекта.

Какие тесты он будет запускать, собрав проект и запустив тесты? И как он собирается «строить» проект? (например, скомпилировать его в двоичный?)

Это означает, как исходный код обрабатывается перед использованием / тестированием. Это зависит от языка, на котором вы пишете. Например, если проект пишется на PHP. Он не собирается встраивать мой код в исполняемый файл, такой как исходный код C / C ++. Он запустит мой PHP-код в интерпретаторе PHP и протестирует его при этом. Он по-прежнему проходит обычный процесс компиляции, который проходит ваш предпочтительный язык.