Сборка и тестирование проектов Java с помощью Gradle

В руководстве описан порядок сборки проектов Java и Gradle с помощью TeamCity. Оно будет полезно разработчикам, никогда ранее не работавшим с TeamCity.

Предварительные условия

Рекомендуется иметь общее представление о Java и фреймворке Gradle. For more information, see the Getting Started with Gradle guide in the Gradle documentation.

Шаг 1. Создание проекта в TeamCity

  1. Нажмите на значок Administration в виде гайки в правом верхнем углу страницы TeamCity.
  2. Нажмите + Create Project и выберите вкладку From a repository URL. В поле Repository URL введите адрес репозитория, например: https://github.com/marcobehlerjetbrains/teamcity-gradle.git. TeamCity предлагает встроенную поддержку всех популярных систем контроля версий: Git, Subversion, Mercurial, Perforce и TFS (как в облачной, так и в локальной версии TeamCity). Поддержка CVS, StarTeam и Visual SourceSafe есть только в локальной версии TeamCity.
  3. Если репозиторий использует аутентификацию, введите имя пользователя и пароль или токен доступа.
  4. Нажмите Proceed.

Если TeamCity успешно подключился к репозиторию, появится следующее окно.

В окне Create Project From URL можно изменить название проекта и название первоначальной конфигурации сборки.

Примечание: в новых версиях появились также поля Default branch и Branch specification, которые позволяют указать, какие именно ветки должен создавать TeamCity. Пока что их следует игнорировать.

  • TeamCity предложит название проекта по умолчанию, но вы можете ввести другое, более подходящее.
  • TeamCity предложит также название конфигурации сборки по умолчанию. Можно оставить предложенное название, при необходимости вы сможете изменить его позже. (Каждый проект TeamCity включает в себя по крайней мере одну конфигурацию сборки, которая содержит все необходимые шаги для создания проекта. Конфигурации сборок TeamCity в других системах непрерывной интеграции часто называются заданиями (jobs).)
  • Нажмите Proceed.

Когда вы нажали Proceed, TeamCity автоматически сканирует репозиторий контроля версий в поисках поддерживаемых технологий, в данном случае — Java и Gradle.

Если TeamCity находит в репозитории файл build.gradle, то автоматически предлагает необходимый шаг сборки для вашего проекта. Этот шаг включает в себя компиляцию проекта Gradle и выполнение всех тестов с помощью gradle clean build.

Не путайте шаги сборки с конфигурацией сборки. Конфигурация сборки может содержать много шагов.

  1. Поставьте флажок рядом с шагом сборки Gradle.
  2. Нажмите Use selected.

Вы успешно настроили репозиторий Gradle для работы с TeamCity:

Шаг 2. Запуск первой сборки

Теперь можно запустить первую сборку.

  1. Нажмите кнопку Run в правом верхнем углу окна, как показано ниже:

Примечание: если вы используете TeamCity Cloud, билд-агент может стать доступным через пару минут. В течение этого времени сборка находится в очереди, пока ее не подхватит доступный агент.

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

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

Шаг 3. Настройка проекта Gradle в TeamCity

После подключения репозитория Gradle к TeamCity можно продолжать разработку и отправлять код в репозиторий.

По умолчанию TeamCity каждые 60 секунд отправляет в основную (main) ветку репозитория системы контроля версий VCS запросы относительно внесенных изменений и запускает единую сборку для всех обнаруженных коммитов.

Создание сборки из веток

Если вы хотите запускать сборку для каждого изменения в любой ветке репозитория, а не только в main, добавьте спецификацию веток с использованием символов подстановки в настройки корня VCS. Обратите внимание: настройки VCS сохраняются для всего проекта TeamCity, а не для конкретной конфигурации сборки. Таким образом, любые внесенные изменения будут применены ко всем конфигурациям сборки, использующим тот же корень VCS.

  1. На странице общей информации о проекте нажмите Edit Project. Если у вас открыта конфигурация сборки Build, можно также нажать Edit Configuration.
  2. Перейдите к VCS Roots (системы контроля версий) и измените корень VCS.
  3. Заполните поле Branch Specification и нажмите Save. Если вы не видите поле Branch Specification, нажмите сначала Show Advanced.

Примеры спецификации ветки:

  • +:refs/heads/* — TeamCity будет проверять наличие изменений во всех ветках проектов, но не будет проверять пул-реквесты на таких платформах, как GitHub, потому что они соответствуют refs/pull/*;
  • +:* — TeamCity будет проверять наличие любых внесенных изменений во всех ветках;
  • ваша собственная спецификация веток.

Теперь TeamCity будет отслеживать все ветки, соответствующие введенной спецификации и отправленные в репозиторий. При обнаружении изменений будет запущена сборка.

Генерация сборок из пул-реквестов

Если вы хотите, чтобы TeamCity автоматически создавал билды из пул-реквестов, отправляемых в репозиторий, можно добавить в конфигурацию сборки функцию Pull Request.

  1. Откройте конфигурацию сборки и нажмите Edit Configuration.
  2. Перейдите к Build Features и нажмите Add Build Feature. Если вы не видите ссылку Build Features, нажмите Show More.
  3. В раскрывающемся списке выберите Pull Requests, а затем выберите свой репозиторий и поставщика услуг репозитория (GitHub, GitLab и т. п.).
  4. При необходимости можно использовать Pull Request Filtering, чтобы отфильтровать пул-реквесты по автору или названию ветки.

Примечание: функция сборки Pull Request прозрачно расширяет спецификацию ветки (подробнее см. предыдущий шаг). Например, при использовании GitHub функция пул-реквеста (незаметно) добавляет к спецификации ветки +:refs/pull/*.

Если используется функция пул-реквестов, рекомендуем убедиться, что ветки пул-реквестов не включены в общую спецификацию ветки явным образом. В противном случае возможности, связанные с пул-реквестами, будут недоступны в TeamCity.

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

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

Commit Status Publisher

При использовании функции пул-реквестов в сочетании с Azure DevOps, Bitbucket Server, GitHub или GitLab, также имеет смысл использовать функцию Commit Status Publisher. Она изменяет статус пул-реквеста на соответствующей платформе в зависимости от результатов сборки.

Чтобы настроить отправку результатов сборки из TeamCity обратно в GitHub, нужно сделать следующее:

  1. Откройте конфигурацию сборки и нажмите Edit Configuration.
  2. Перейдите к Build Features и нажмите Add Build Feature.
  3. Выберите в раскрывающемся списке Commit Status Publisher, затем выберите репозиторий и издателя (GitHub, GitLab и т. п.).
  4. Укажите токен доступа с правами, позволяющими публиковать статус коммита.
  5. Нажмите Save.

Когда TeamCity запустит сборку, вы сразу увидите, привели ли внесенные изменения к ошибке в сборке, прямо на вкладке Pull Request в GitHub (появится соответствующий значок).