В руководстве описан порядок сборки проектов Java и Gradle с помощью TeamCity. Оно будет полезно разработчикам, никогда ранее не работавшим с TeamCity.
Предварительные условия
Рекомендуется иметь общее представление о Java и фреймворке Gradle. For more information, see the Getting Started with Gradle guide in the Gradle documentation.
Если TeamCity успешно подключился к репозиторию, появится следующее окно.
В окне Create Project From URL можно изменить название проекта и название первоначальной конфигурации сборки.
Примечание: в новых версиях появились также поля Default branch и Branch specification, которые позволяют указать, какие именно ветки должен создавать TeamCity. Пока что их следует игнорировать.
Когда вы нажали Proceed, TeamCity автоматически сканирует репозиторий контроля версий в поисках поддерживаемых технологий, в данном случае — Java и Gradle.
Если TeamCity находит в репозитории файл build.gradle, то автоматически предлагает необходимый шаг сборки для вашего проекта. Этот шаг включает в себя компиляцию проекта Gradle и выполнение всех тестов с помощью gradle clean build
.
Не путайте шаги сборки с конфигурацией сборки. Конфигурация сборки может содержать много шагов.
Вы успешно настроили репозиторий Gradle для работы с TeamCity:
Теперь можно запустить первую сборку.
Примечание: если вы используете TeamCity Cloud, билд-агент может стать доступным через пару минут. В течение этого времени сборка находится в очереди, пока ее не подхватит доступный агент.
Если вы используете локальную версию TeamCity с локальными билд-агентами, сборка начнется сразу.
После начала сборки вы будете перенаправлены на страницу общей информации о сборке. При этом откроется вкладка Build Log, где в реальном времени отображаются данные сборки. После окончания сборки можно посмотреть результаты тестов или полный журнал сборки.
После подключения репозитория Gradle к 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 будет проверять внешнюю платформу на наличие пул-реквестов и запускать сборку для тех, которые соответствуют правилам конфигурации.
Примечание: при использовании этой функции в публичных репозиториях нужно соблюдать осторожность, потому что кто угодно может отправить в репозиторий вредоносный код, для которого не нужно запускать сборку.
При использовании функции пул-реквестов в сочетании с Azure DevOps, Bitbucket Server, GitHub или GitLab, также имеет смысл использовать функцию Commit Status Publisher. Она изменяет статус пул-реквеста на соответствующей платформе в зависимости от результатов сборки.
Чтобы настроить отправку результатов сборки из TeamCity обратно в GitHub, нужно сделать следующее:
Когда TeamCity запустит сборку, вы сразу увидите, привели ли внесенные изменения к ошибке в сборке, прямо на вкладке Pull Request в GitHub (появится соответствующий значок).