TeamCity 2024.07 : nouveau mécanisme de licence, page Problems remaniée, GitHub Checks Webhook Trigger, et plus encore

TeamCity 2024.07 est là ! Avec cette version, nous introduisons un certain nombre de fonctionnalités très attendues, telles que le nouveau mécanisme de licence via le compte JetBrains Account unifié, qui simplifie la gestion des licences.

Un nouveau GitHub Checks Webhook Trigger permet également de mettre instantanément un build en file d'attente après un commit sur GitHub et fournit des mises à jour au format texte enrichi.

La page Problems actualisée offre de plus un emplacement centralisé pour examiner tout problème lié aux tests et aux builds TeamCity.

Nouveau mécanisme de licence pour les comptes TeamCity

Dans la version 2024.07, nous introduisons une option permettant aux administrateurs TeamCity d'activer des licences à l'aide d'un compte JetBrains Account unifié. Vous pouvez à présent connecter votre compte JetBrains Account à votre instance TeamCity (y compris TeamCity Professional) et récupérer les licences du compte JetBrains Account.

Cette nouvelle fonctionnalité vise à simplifier la gestion des licences de serveur et d'agent TeamCity grâce à votre compte JetBrains Account.

Vous pouvez désormais vous connecter simplement à votre compte JetBrains Account à partir de la page Licenses dans TeamCity et sélectionner une licence de serveur pour l'activation. Une fois connecté, TeamCity mettra automatiquement à jour toutes les licences de serveur et d'agent. Plus besoin de saisir manuellement les clés de licence pour des agents supplémentaires ou des renouvellements de licence.

Pour en savoir plus sur l'activation des licences via votre compte JetBrains Account, consultez notre documentation.

Chemin personnalisé dans le référentiel pour les paramètres versionnés

Dans TeamCity, vous pouvez configurer vos projets et paramètres par programmation en utilisant le format Kotlin DSL et XML.

Auparavant, si un projet avait des paramètres versionnés stockés dans VCS, TeamCity suivait uniquement le répertoire .teamcity. TeamCity pouvait toujours stocker les paramètres versionnés pour tous les sous-projets dans un même référentiel, mais uniquement si les paramètres versionnés étaient activés pour le projet principal. Dans certains scénarios, ce n'était pas pratique.

Par exemple, un DSL défectueux dans un projet principal bloquait les mises à jour de tous les sous-projets et autres builds.

Autre inconvénient de l'approche précédente : si des modifications apportées à un projet déclenchaient la compilation du Kotlin DSL, les paramètres étaient appliqués aux autres projets stockés dans le même référentiel, même lorsque les modifications appliquées n'étaient pas censées les affecter.

Nous ajoutons à présent la possibilité de configurer des chemins personnalisés dans le référentiel pour les paramètres versionnés dans TeamCity.

Page Problems remaniée

TeamCity offre un aperçu des problèmes et des investigations en cours au niveau du projet et du build. Les utilisateurs peuvent gérer les erreurs de configuration de build, les tests ayant échoué, les problèmes ignorés et les investigations en cours, ainsi que le responsable et l'état de chaque ticket.

Nous avons repensé l'interface utilisateur pour clarifier l'aperçu de tous les problèmes et de leur état, que vous trouverez désormais sur la page unifiée Problems.

GitHub Checks Webhook Trigger

Cette nouvelle fonctionnalité de TeamCity vous permet de mettre les builds en file d'attente immédiatement après avoir envoyé un commit vers GitHub. Elle publie également l'état du build au format texte enrichi à l'aide de Markdown sur GitHub.

TeamCity publie l'état, mais il crée également une GitHub Check Run qui exécute des vérifications immédiatement après que quelqu'un a envoyé du code en mode push. Les utilisateurs peuvent ainsi afficher facilement l'état et les détails dans GitHub. Plus besoin de basculer entre GitHub et TeamCity.

Par ailleurs, en cas de problème, les utilisateurs peuvent réexécuter les vérifications depuis GitHub sans avoir à passer à TeamCity.

Ce déclencheur est compatible avec les connexions de l'application GitHub pour lesquelles les webhooks sont activés.

Téléchargement de clés SSH vers le serveur lors de la création de projets ou de racines VCS à partir d'URL

Dans TeamCity, vous pouvez créer des projets ou des racines VCS à partir d'une URL.

Auparavant, le formulaire permettant de créer un projet ou une configuration de build à partir d'une URL acceptait uniquement des informations d'identification telles qu'un nom d'utilisateur et un mot de passe ou un jeton d'accès.

Nous avons maintenant remanié le formulaire d'authentification afin que vous puissiez choisir manuellement l'option Password/Access token ou SSH key comme type d'authentification.

TeamCity détectera et suggérera également automatiquement le type approprié lorsque vous insérez l'URL dans le champ correspondant. Vous pouvez également mettre en ligne une nouvelle clé SSH sur la même page.

Prise en charge des mappages à l'identique de Perforce

Perforce Helix Server dispose depuis quelque temps d'une fonctionnalité de mappage un-à-plusieurs, qui permet aux utilisateurs de mapper un chemin de dépôt unique vers plusieurs emplacements dans un espace de travail client. Cette fonctionnalité est également connue sous le nom de mappage à l'identique (ditto mapping).

À partir de TeamCity 2024.07, le mappage à l'identique (ditto mapping) est également pris en charge.

Découvrez la liste complète des fonctionnalités de la version 2024.07 dans notre documentation.

Comme toujours, n'hésitez pas à nous contacter pour toute question ou suggestion à l'aide du forum ou du formulaire de contact sur notre site web.