Builds et tests pour Java avec Gradle

1. Cliquez sur l'icône en forme de roue Administration dans le coin supérieur droit de la page TeamCity.
   
2. Cliquez sur + Create Project et sélectionnez l'onglet From a repository URL. In the Repository URL field, enter your repository, for example: https://github.com/marcobehlerjetbrains/teamcity-gradle.git. TeamCity gère nativement tous les principaux systèmes de gestion des versions : Git, Subversion, Mercurial, Perforce et TFS (TeamCity Cloud et installation locale). La prise en charge de CVS, StarTeam et Visual SourceSafe est uniquement disponible dans les installations locales de TeamCity.
3. Si votre dépôt nécessite une authentification, saisissez votre nom d'utilisateur et votre mot de passe / jeton d'accès.
4. Cliquez sur Proceed.

Si TeamCity se connecte avec succès à votre dépôt, le message ci-dessous s'affiche.

Dans la boîte de dialogue Create Project From URL, vous avez la possibilité de modifier le nom du projet et le nom de la configuration de build initiale.

Remarque : Dans les versions plus récentes de TeamCity, vous verrez également les champs Default branch et Branch specification, qui vous permettent de spécifier les branches que TeamCity doit créer. Ignorez-les pour l'instant.

• TeamCity propose un nom de projet par défaut, mais vous pouvez choisir un nom plus approprié pour votre projet si vous le souhaitez.
• TeamCity suggère également un nom de configuration de build par défaut. Ici, vous pouvez laisser la valeur par défaut et la modifier plus tard si nécessaire. (Chaque projet TeamCity est constitué d'au moins une configuration de build, qui contient toutes les étapes nécessaires pour développer votre projet. Les configurations de build de TeamCity sont souvent appelées Jobs dans d'autres systèmes de CI.)
• Cliquez sur Proceed.

Après avoir cliqué sur Proceed, TeamCity analyse automatiquement votre dépôt de contrôle de version à la recherche de technologies prises en charge, dans ce cas Java et Gradle.

Si TeamCity détecte un fichier build.gradle dans votre dépôt, il suggérera automatiquement des étapes de build pour votre projet qui impliquent la compilation de votre projet Gradle et l'exécution de ses tests en effectuant un gradle clean build.

Les étapes de build ne doivent pas être confondues avec une configuration de build. Une configuration de build peut potentiellement contenir de nombreuses étapes de build.

1. Cochez la case adjacente à l'étape de build Gradle.
2. Cliquez sur Use selected.

Vous avez maintenant configuré avec succès votre dépôt Gradle avec TeamCity :

Vous pouvez à présent exécuter vos premières builds.

1. Cliquez sur le bouton Run dans le coin supérieur droit de la fenêtre, comme illustré ci-dessous :

Remarque : si vous utilisez TeamCity Cloud, il vous faudra peut-être attendre quelques minutes avant qu'un agent de build soit disponible. Pendant ce temps, votre build attendra dans la file d'attente jusqu'à ce qu'elle soit prise en charge par un agent disponible.

Si vous utilisez des installations locales de TeamCityTeamCity avec des agents de build locaux, votre build commencera immédiatement.

Une fois votre build démarré, vous serez redirigé vers la page d'aperçu du build avec l'onglet Build Log ouvert, qui affiche les données de votre build en temps réel. Une fois que le build a fini de s'exécuter, vous pouvez consulter les résultats de test ou parcourir le journal de build complet.

Maintenant que votre dépôt Gradle est connecté à TeamCity, vous pouvez continuer à développer et à transmettre votre code à votre dépôt.

Par défaut, TeamCity interroge la branche principale de votre dépôt VCS toutes les 60 secondes pour les changements entrants et déclenche un build (combiné) pour tous les commits détectés.

Génération de branches

Si vous voulez déclencher un build pour chaque changement apporté à n'importe quelle branche de votre dépôt, et pas seulement à la branche principale, ajoutez une spécification de branche avec un caractère générique à vos paramètres racine VCS. Notez que les paramètres VCS appartiennent au projet TeamCity, et non à une seule configuration de build. Par conséquent, toute modification apportée est appliquée à toutes les configurations de build qui utilisent la même racine VCS.

1. Sur la page de présentation du projet, cliquez sur Edit Project. Alternativement, si la configuration de build Build est ouverte, cliquez sur Edit Configuration.
2. Accédez à VCS Roots (systèmes de contrôle de version) et modifiez votre racine VCS.
3. Remplissez le champ de saisie Branch Specification, puis cliquez sur Save. Si le champ de saisie Branch Specification n'apparaît pas, cliquez d'abord sur Show Advanced.

Exemples de spécifications de branches :

• +:refs/heads/* : TeamCity vérifiera les changements dans toutes les branches de vos projets, mais ne vérifiera pas les requêtes Pull sur des plateformes comme GitHub dans la mesure où elles correspondent à refs/pull/*.
• +:* : TeamCity vérifiera toutes les modifications entrantes sur toutes les branche.
• Votre propre spécification de branche personnalisée.

TeamCity surveille désormais toutes les branches qui sont conformes à votre spécification de branche et qui sont transmises à votre dépôt, en vérifiant les changements entrants, et il exécute les builds en conséquence.

Création de requêtes pull

Si vous souhaitez que TeamCity fasse un build automatique des requêtes Pull faites sur votre dépôt, vous pouvez ajouter la fonctionnalité de build Pull Request à votre configuration de build.

1. Ouvrez votre configuration de build et cliquez sur Edit Configuration.
2. Accédez à Build Features, puis cliquez sur Add Build Feature. Si le lien Build Features n'apparaît pas, cliquez sur Show More.
3. Sélectionnez Pull Requests dans la liste déroulante et choisissez votre dépôt, ainsi que le fournisseur de dépôt (GitHub, GitLab, ou similaire).
4. En option, appliquez le filtrage de Pull Request, par auteur ou nom de branche.

Remarque : la fonctionnalité de build Pull Request étend de manière transparente la spécification de branche (voir l'étape précédente pour plus d'informations). Par exemple, dans le cas de GitHub, la fonctionnalité de requête Pull ajoute (de manière invisible) +:refs/pull/* à votre spécification de branche.

Nous recommandons de vous assurer que les branches de requêtes Pull ne sont pas incluses dans votre spécification de branche générale lorsque la fonctionnalité de requête Pull est utilisée. Sinon, les fonctionnalités liées aux requêtes Pull ne seront pas disponibles dans TeamCity.

TeamCity détecte désormais les requêtes Pull sur la plateforme externe et déclenche un build pour celles qui correspondent à vos règles de configuration.

Remarque : Vous devriez utiliser cette fonctionnalité avec prudence sur les dépôts publics, car n'importe qui pourrait publier du code nuisible dans le dépôt (que vous ne voudriez surtout pas inclure dans votre build).

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. Cette fonctionnalité met à jour le statut de la requête Pull sur la plateforme correspondante avec les résultats du build.

Pour configurer TeamCity afin de transmettre les résultats du build à GitHub, veuillez suivre les étapes suivantes :

1. Ouvrez votre configuration de build et cliquez sur Edit Configuration.
2. Accédez à Build Features, puis cliquez sur Add Build Feature.
3. Sélectionnez Commit Status Publisher dans la liste déroulante et choisissez votre dépôt, ainsi qu'un éditeur (GitHub, GitLab, ou similaire).
4. Fournissez un jeton d'accès avec les autorisations appropriées pour publier les statuts de commit.
5. Cliquons sur Save.

Après que TeamCity a exécuté un build, vous pourrez désormais facilement voir si les changements ont causé un échec de build directement depuis l'onglet Pull Request sur GitHub (coche verte).