В руководстве описан порядок сборки проектов Java и Maven с помощью TeamCity. Оно будет полезно разработчикам, никогда ранее не работавшим с TeamCity.
Предварительные условия
Рекомендуется иметь общее представление о Java и фреймворке Maven. For more information, see the Getting Started with Maven guide in the Maven documentation.
Если TeamCity успешно подключился к репозиторию, появится следующее окно.
В окне Create Project From URL можно изменить название проекта и название первоначальной конфигурации сборки.
Примечание: в новых версиях появились также поля Default branch и Branch specification, которые позволяют указать, какие именно ветки должен создавать TeamCity. На этом этапе их можно игнорировать.
Когда вы нажали Proceed, TeamCity автоматически сканирует репозиторий контроля версий в поисках поддерживаемых технологий, в данном случае — Java и Maven.
Если TeamCity находит в репозитории файл pom.xml, то автоматически предлагает необходимый шаг сборки для вашего проекта. Этот шаг включает в себя компиляцию проекта Maven и выполнение всех тестов с помощью mvn clean test
.
Не путайте шаги сборки с конфигурацией сборки. Конфигурация сборки может содержать много шагов.
Вы успешно настроили репозиторий Maven для работы с TeamCity:
Теперь можно запустить первую сборку.
Примечание: если вы используете TeamCity Cloud, билд-агент может стать доступным через пару минут. В течение этого времени сборка находится в очереди, пока ее не подхватит доступный агент.
Если вы используете локальную версию TeamCity с локальными билд-агентами, сборка начнется сразу.
После начала сборки вы будете перенаправлены на страницу общей информации о сборке. При этом откроется вкладка Build Log, где в реальном времени отображаются данные сборки. После окончания сборки можно посмотреть результаты тестов или полный журнал сборки.
После подключения репозитория Maven к TeamCity можно продолжать разработку и отправлять код в репозиторий.
По умолчанию TeamCity каждые 60 секунд отправляет в основную (main) ветку репозитория системы контроля версий VCS запросы относительно внесенных изменений и запускает единую сборку для всех обнаруженных коммитов.
Если вы хотите запускать сборку для каждого изменения в любой ветке репозитория, а не только в main, добавьте спецификацию веток с использованием символов подстановки в настройки корня VCS. Обратите внимание: настройки VCS сохраняются для всего проекта TeamCity, а не для конкретной конфигурации сборки. Таким образом, любые внесенные изменения будут применены ко всем конфигурациям сборки, использующим тот же корень VCS.
Примеры спецификации ветки:
+:refs/heads/*
— TeamCity будет проверять наличие изменений во всех ветках проектов, но не будет проверять пул-реквесты на таких платформах, как GitHub, потому что они соответствуют refs/pull/*
; +:*
— TeamCity будет проверять наличие любых внесенных изменений во всех ветках; Теперь TeamCity будет отслеживать все ветки, соответствующие введенной спецификации и отправленные в репозиторий. При обнаружении изменений будет запущена сборка.
Если вы хотите, чтобы TeamCity автоматически создавал сборки из пул-реквестов, отправляемых в репозиторий, можно добавить в конфигурацию сборки функцию Pull Request.
Примечание: функция сборки Pull Request прозрачно расширяет спецификацию ветки (подробнее см. предыдущий шаг). Например, при использовании GitHub функция пул-реквеста (незаметно) добавляет к спецификации ветки +:refs/pull/*
.
Если используется функция пул-реквестов, рекомендуем убедиться, что ветки пул-реквестов не включены в общую спецификацию ветки явным образом. В противном случае возможности, связанные с пул-реквестами, будут недоступны в TeamCity.
Теперь TeamCity будет проверять внешнюю платформу на наличие пул-реквестов и запускать сборку для тех, которые соответствуют правилам конфигурации.
Примечание: при использовании этой функции в публичных репозиториях нужно соблюдать осторожность, потому что кто угодно может отправить в репозиторий вредоносный код, для которого не нужно запускать сборку.
When using the pull requests feature in combination with Azure DevOps, Bitbucket Server, GitHub, or GitLab, it also makes sense to use the Commit Status Publisher build feature. Она изменяет статус пул-реквеста на соответствующей платформе в зависимости от результатов сборки.
Чтобы настроить отправку результатов сборки из TeamCity обратно в GitHub, нужно сделать следующее:
Когда TeamCity запустит сборку, вы сразу увидите, привели ли внесенные изменения к ошибке в сборке, прямо на вкладке Pull Request в GitHub (появится соответствующий значок). Кроме того, отображается ссылка на сервер TeamCity, так что вы можете посмотреть результаты тестирования.