Сборка и тестирование проектов Python

1. Нажмите на значок Administration в виде гайки в правом верхнем углу страницы TeamCity.
   
2. Нажмите + Create Project и выберите вкладку From a repository URL. В поле Repository URL введите адрес репозитория, например: https://github.com/marcobehlerjetbrains/teamcity-python.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 автоматически сканирует репозиторий контроля версий в поисках поддерживаемых технологий, в данном случае — Python.

Когда TeamCity находит в репозитории файл .py, то автоматически предлагает необходимые шаги сборки для вашего проекта. Для репозитория, используемого в этом руководстве, автоматически определенные шаги сборки включают в себя запуск файла main.py или setup.py, но вам может быть нужно совсем другое.

Вместо этого, возможно, лучше добавлять в проект Python следующие шаги сборки по умолчанию:

1. Linting — выполнение Flake8 или PyLint.
2. Testing — выполнение PyTest или UnitTest.

Давайте добавим эти два шага сборки в проект вместо предложенных автоматически.

Сначала добавляем шаг Flake8 linting в проект TeamCity.

1. Нажмите Build Steps, чтобы сбросить шаги, предложенные автоматически.
2. Нажмите Add Build Step и выберите Runner type: Python, чтобы добавить шаг, предназначенный для сборки кода Python.
3. Выберите Command: Flake8, поскольку в этом проекте Python для проверки кода используется зависимость Flake8. Если бы для проверки кода использовался Pylint, нужно было бы выбрать этот вариант.
4. В поле Script or module arguments можно указать директорию для проверки. Если вы работаете с репозиторием Python из этого руководства, укажите src/anewtodolist. Можно оставить поле пустым, тогда проверка будет выполнена по всему проекту.
5. При необходимости можно выбрать другую основную версию Python (Python version), если ваш проект все еще использует 2.x.
6. Инструмент среды: в этом проекте для всех зависимостей, таких как Flake8 и PyTest, используется Virtualenv. Обязательно выберите Virtualenv как инструмент среды, чтобы включить его поддержку.
7. Нажмите Save.

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

Теперь давайте добавим в проект шаг PyTest.

1. (Опционально) Если у вас не открыта страница Build Steps Overview, нажмите Build Steps, чтобы сбросить шаги, предложенные автоматически.
2. Нажмите Add Build Step и выберите Runner type: Python, чтобы добавить шаг, предназначенный для сборки кода Python.
3. Выберите Command: Pytest, поскольку в этом проекте Python для тестирования используется зависимость Pytest. Если бы для тестирования использовался UnitTest, нужно было бы выбрать этот вариант.
4. При необходимости в поле Script or module arguments можно указать директорию для тестирования. Если тесты находятся в папке /tests, оставьте поле пустым: инструмент запуска тестов Python найдет ее автоматически.
5. При необходимости можно выбрать другую основную версию (Python version), если ваш проект все еще использует 2.x.
6. Инструмент среды: в этом проекте для всех зависимостей, таких как Flake8 и PyTest, используется Virtualenv. Обязательно выберите Virtualenv как инструмент среды, чтобы включить его поддержку.
7. Нажмите Save.

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

1. Нажмите кнопку Run в правом верхнем углу окна, как показано ниже.
2. Дождитесь запуска и окончания сборки.

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

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

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

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

После подключения репозитория Python к 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 (появится соответствующий значок).