Este guia mostra como construir projetos Python com o TeamCity e é recomendado para desenvolvedores que estão usando o TeamCity pela primeira vez.
Pré-requisitos
We recommend that you have a basic understanding of Python and PyTest.
Para mais informações, consulte a documentação do Python.
Se o TeamCity conectar com sucesso ao seu repositório, você verá a seguinte caixa de diálogo.
Na caixa de diálogo Create Project From URL, você poderá alterar o nome do projeto e o nome da configuração de build inicial.
Nota: Nas versões mais recentes do TeamCity, você também verá os campos Default branch e Branch specification, que permitem especificar quais branches o TeamCity deve construir. Ignore-os por enquanto.
Depois de clicar em Proceed, o TeamCity verifica automaticamente seu repositório de controle de versão em busca de tecnologias suportadas, neste caso Python.
Quando o TeamCity detecta um arquivo .py no seu repositório, ele irá sugerir automaticamente uma ou mais etapas de build para seu projeto. Para o repositório usado neste tutorial, as etapas de build detectadas automaticamente executariam seus arquivos main.py ou setup.py, que podem não ser o que você deseja.
Em vez disso, faz sentido ter as seguintes etapas de build adicionadas ao seu projeto Python como default:
Em vez de escolher uma das etapas de build detectadas automaticamente, vamos incluir essas duas etapas de build no seu projeto.
Comece incluindo uma etapa Flake8 linting ao seu projeto TeamCity.
Se você criou sua etapa de build com sucesso, verá a seguinte caixa de diálogo.
Em seguida, vamos adicionar uma etapa PyTest ao seu projeto.
Você agora poderá executar seus primeiros builds.
Observação: Se você estiver usando o TeamCity Cloud, pode levar alguns minutos antes que um agente de build esteja disponível. Durante esse período, seu build aguardará na fila até que seja selecionado por um agente disponível.
Se você estiver usando o TeamCity On-Premises com agentes de build locais, seu build começará imediatamente.
Assim que seu build começar, você será redirecionado para a página de visão geral do build com a aba Build Log aberta. Ela mostrará os dados em tempo real relacionados ao seu build.
Depois que o build executar, você será redirecionado para uma página com a visão geral do build. Agora você pode dar uma olhada em seus resultados de teste e inspeções ou navegar no log de construção completo, a partir da página com a visão geral do build.
Agora que seu repositório Python está conectado ao TeamCity, você pode continuar a desenvolver e fazer push do seu código para o repositório.
Por default, TeamCity irá pesquisar o branch main do seu repositório VCS a cada 60 segundos para mudanças de entrada e acionar um build (combinado) para todos os commits detectados.
Se você deseja disparar uma build para cada alteração em qualquer branch do seu repositório, não apenas no branch main, adicione uma especificação de branch curinga às configurações do root do seu VCS. Observe que as configurações de VCS pertencem ao projeto TeamCity como um todo, não a uma única configuração de build. Portanto, quaisquer alterações que você fizer serão aplicadas a todas as configurações de build que usam a mesma root no VCS.
Exemplos de especificações de branch:
+:refs/heads/*
: o TeamCity irá verificar se há mudanças em todos os branches de seus projetos, mas não verificará solicitações pull em plataformas como GitHub, pois essas correspondem a refs/pull/*
. +:*
: o TeamCity irá verificar se houve quaisquer alterações recebidas em qualquer branch. O TeamCity agora vai monitorar todos os branches que estão em conformidade com a especificação do seu branch e que foram enviadas para o seu repositório, monitorando alterações recebidas, e executará os builds de acordo.
Se você deseja que o TeamCity construa automaticamente as solicitações pull que são feitas no seu repositório, você pode adicionar o Pull Request build feature à sua configuração de build.
Observação: O recurso de build Pull Request expande de forma transparente a especificação do branch (veja o passo anterior para mais informações). Por exemplo, no caso do GitHub, o recurso de solicitação pull irá adicionar +:refs/pull/*
, de forma invisível, à sua especificação de branch.
Recomendamos garantir que os branches de solicitações pull não sejam incluídos na sua especificação geral de branch quando o recurso de solicitação pull for usado, caso contrário, os recursos relacionados à solicitações pull não estarão disponíveis no TeamCity.
Agora o TeamCity irá monitorar a plataforma externa para detectar solicitações de pull e disparar um build para aquelas que corresponderem às suas regras de configuração.
Observação: Você deve usar este recurso com cuidado em repositórios públicos, pois qualquer pessoa pode enviar código malicioso para o repositório (código que você não vai querer construir).
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. Este recurso atualizará o status da solicitação pull, na plataforma correspondente, com os resultados do build.
Para configurar o TeamCity para relatar os resultados do build de volta ao GitHub, você deve seguir as seguintes etapas:
Depois que o TeamCity executar uma build, você poderá facilmente descobrir se as alterações causaram alguma falha no build através da aba Pull Request no GitHub (marca de seleção verde).