Compilando e testando Python

1. Clique na engrenagem Administration no canto superior direito da página do TeamCity.
   
2. Clique em + Create Project e selecione a aba From a repository URL. In the Repository URL field, enter your repository, for example: https://github.com/marcobehlerjetbrains/teamcity-python.git. O TeamCity suporta todos os mais populares sistemas de controle de versão: Git, Subversion, Mercurial, Perforce e TFS (TeamCity Cloud + On-Premises). O suporte a CVS, StarTeam e Visual SourceSafe está disponível apenas no TeamCity On-Premises.
3. Se seu repositório necessita de autenticação, insira seu nome de usuário e senha/token de acesso.
4. Clique em Proceed.

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.

• O TeamCity irá sugerir um nome de projeto default, mas você pode escolher um nome mais adequado para seu projeto, se desejar.
• O TeamCity também vai sugerir um nome de configuração de build default. Não há problema em deixar o nome default aqui. Você pode alterá-lo mais tarde, se necessário. (Todo projeto TeamCity consiste em pelo menos uma configuração de build, que contém todas as etapas necessárias para construir seu projeto. As configurações de build do TeamCity são frequentemente chamadas de jobs em outros sistemas de CI.)
• Clique em Proceed.

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:

1. Uma etapa de build de Linting, executando Flake8 ou PyLint
2. Uma etapa de build de Testing, executando PyTest ou UnitTest.

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.

1. Clique em Build Steps para descartar as etapas de build detectadas automaticamente.
2. Clique em Add Build Step e escolha Runner type: Python para incluir uma etapa de build capaz de compilar código Python.
3. Escolha Command: Flake8, já que este projeto Python tem uma dependência Flake8 para linting. Se o seu projeto estivesse usando Pylint para linting, você escolheria Pylint.
4. Você pode especificar o diretório no qual deseja realizar o linting no campo Script or module arguments. Defina-o como “src/anewtodolist” se estiver trabalhando com o repositório Python deste tutorial. Ou, opcionalmente, deixe-o vazio, para fazer linting em todo o projeto.
5. Opcionalmente: Escolha uma versão Python principal diferente, se seu projeto ainda usar 2.x.
6. Ferramenta de ambiente: Este projeto usa o Virtualenv para todas as dependências necessárias, como Flake8 e PyTest. Certifique-se de habilitar o suporte a Virtualenv selecionando-o como a ferramenta de ambiente.
7. Clique em Save.

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.

1. (Opcional) Se você não estiver na página Build Steps Overview, clique em Build Steps para descartar as etapas de build detectadas automaticamente.
2. Clique em Add Build Step e escolha Runner type: Python para incluir uma etapa de build capaz de compilar código Python.
3. Escolha Command: Pytest , já que este projeto Python tem uma dependência Pytest para o teste. Se o seu projeto estivesse usando UnitTest para testes, você escolheria UnitTest.
4. Opcionalmente: Você pode especificar o diretório no qual deseja realizar os testes no campo Script or module arguments. Ou deixe-o vazio, se seus testes estiverem na pasta /tests, que o executor Python irá detectar automaticamente.
5. Opcionalmente: Escolha uma versão Python principal diferente, se seu projeto ainda usar 2.x.
6. Ferramenta de ambiente: Este projeto usa o Virtualenv para todas as dependências necessárias, como Flake8 e PyTest. Certifique-se de habilitar o suporte a Virtualenv selecionando-o como a ferramenta de ambiente.
7. Clique em Save.

Você agora poderá executar seus primeiros builds.

1. Clique no botão Run no canto superior direito da janela, conforme mostrado abaixo.
2. Aguarde o build iniciar e terminar.

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.

Construindo branches

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.

1. Na página de visão geral do projeto, clique em Edit Project. Como alternativa, se você estiver com a configuração de build Build aberta, clique em Edit Configuration.
2. Navegue até VCS Roots (sistemas de controle de versão) e edite a root do seu VCS.
3. Preencha o campo de entrada Branch Specification e clique em Save. Se você não conseguir ver o campo de entrada Branch Specification, clique primeiro em Show Advanced.

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.
• Sua própria especificação de branch personalizada.

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.

Compilando solicitações Pull

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.

1. Abra sua configuração de build e clique em Edit Configuration.
2. Navegue até Build Features e clique em Add Build Feature. Se você não puder ver o link Build Features, clique em Show More.
3. Selecione Pull Requests no menu dropdown e escolha seu repositório, assim como o provedor de repositório (GitHub, GitLab ou similar).
4. Opcionalmente, aplique o Pull Request Filtering, por autor ou nome do branch.

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).

Commit Status Publisher

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:

1. Abra sua configuração de build e clique em Edit Configuration.
2. Navegue até Build Features e clique em Add Build Feature.
3. Selecione Commit Status Publisher no menu dropdown e escolha seu repositório e um editor (GitHub, GitLab ou similar).
4. Forneça um token de acesso com direitos suficientes para publicar status de commit.
5. Clique em Save.

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).