В руководстве описан порядок создания проектов Python с помощью TeamCity. Оно будет полезно разработчикам, никогда ранее не работавшим с TeamCity.
Предварительные условия
We recommend that you have a basic understanding of Python and PyTest.
Подробнее — в документации Python.
Если TeamCity успешно подключился к репозиторию, появится следующее окно.
В окне Create Project From URL можно изменить название проекта и название первоначальной конфигурации сборки.
Примечание: в новых версиях появились также поля Default branch и Branch specification, которые позволяют указать, какие именно ветки должен создавать TeamCity. На этом этапе их можно игнорировать.
Когда вы нажали Proceed, TeamCity автоматически сканирует репозиторий контроля версий в поисках поддерживаемых технологий, в данном случае — Python.
Когда TeamCity находит в репозитории файл .py, то автоматически предлагает необходимые шаги сборки для вашего проекта. Для репозитория, используемого в этом руководстве, автоматически определенные шаги сборки включают в себя запуск файла main.py или setup.py, но вам может быть нужно совсем другое.
Вместо этого, возможно, лучше добавлять в проект Python следующие шаги сборки по умолчанию:
Давайте добавим эти два шага сборки в проект вместо предложенных автоматически.
Сначала добавляем шаг Flake8 linting в проект TeamCity.
Если TeamCity успешно создал шаг сборки, появится следующее окно.
Теперь давайте добавим в проект шаг PyTest.
Теперь можно запустить первую сборку.
Примечание: если вы используете TeamCity Cloud, билд-агент может стать доступным через пару минут. В течение этого времени сборка находится в очереди, пока ее не подхватит доступный агент.
Если вы используете локальную версию TeamCity с локальными билд-агентами, сборка начнется сразу.
После начала сборки вы будете перенаправлены на страницу общей информации о сборке. При этом откроется вкладка Build Log, где в реальном времени отображаются данные сборки.
После выполнения сборки вы будете перенаправлены на страницу общей информации о сборке. Здесь можно посмотреть результаты тестов и инспекций или полный журнал сборки.
После подключения репозитория Python к 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 (появится соответствующий значок).