Ce guide vous montre comment générer des projets Python avec TeamCity. Il est recommandé pour les développeurs et développeuses qui font leurs tout premiers pas sur TeamCity.
Conditions préalables
We recommend that you have a basic understanding of Python and PyTest.
Pour plus d'informations, consultez la documentation de Python.
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.
Une fois que vous avez cliqué sur Proceed, TeamCity analyse automatiquement votre dépôt de contrôle de version à la recherche des technologies prises en charge, dans ce cas Python.
Si TeamCity détecte un fichier .py dans votre dépôt, il suggère automatiquement une ou plusieurs étapes de build pour votre projet. Pour le référentiel utilisé dans ce tutoriel, ces étapes de build auto-détectées exécuteraient vos fichiers main.py ou setup.py. Ce n'est pas forcément ce que vous souhaitez.
Il est plus judicieux d'ajouter par défaut les étapes de build suivantes à votre projet Python :
Au lieu de choisir l'une des étapes de build détectées automatiquement, ajoutons plutôt ces deux étapes de build à votre projet.
Vous allez commencer par ajouter une étape Linting Flake8 à votre projet TeamCity.
Si vous avez créé avec succès votre étape de build, la boîte de dialogue suivante s'affiche alors.
Ajoutons une étape PyTest à votre projet.
Vous pouvez à présent exécuter vos premières builds.
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.
Après l'exécution de la build, vous serez redirigé·e vers la page de vue d'ensemble de la build. Vous pouvez maintenant consulter les résultats de vos tests et de vos inspections, ou parcourir le journal complet de la build depuis la page de vue d'ensemble de la build.
Maintenant que votre dépôt Python est connecté à TeamCity, vous pouvez continuer à développer et à envoyer votre code vers le dépôt en mode push.
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.
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.
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. 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.
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.
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).
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 :
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).