Este guia mostra como construir projetos Java e Gradle com o TeamCity e é recomendado para desenvolvedores que estão usando o TeamCity pela primeira vez.
Pré-requisitos
Recomendamos que você tenha um conhecimento básico de Java e do framework Gradle. For more information, see the Getting Started with Gradle guide in the Gradle documentation.
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 Java e Gradle.
Se o TeamCity detectar um arquivo build.gradle no seu repositório, ele irá automaticamente sugerir uma etapa de build para seu projeto envolvendo a compilação do seu projeto Gradle e a execução dos seus testes através de um gradle clean build
.
As etapas de build não devem ser confundidas com uma configuração de build. Uma configuração de build pode conter, potencialmente, várias etapas de build.
Você acaba de configurar com sucesso seu repositório Gradle com o TeamCity:
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 a execução do build terminar, você pode dar uma olhada nos seus resultados de teste ou navegar no build log completo.
Agora que seu repositório Gradle 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).