Diese Anleitung zeigt Ihnen, wie Sie Python-Projekte mit TeamCity kompilieren können. Die Anleitung richtet sich an Entwickler*innen ohne TeamCity-Erfahrung.
Voraussetzungen
We recommend that you have a basic understanding of Python and PyTest.
Weitere Informationen finden Sie in der Python-Dokumentation.
Wenn TeamCity erfolgreich eine Verbindung zu Ihrem Repository hergestellt hat, sehen Sie den folgenden Dialog:
Im Dialog Create Project From URL haben Sie die Möglichkeit, den Projektnamen und den Namen der anfänglichen Build-Konfiguration zu ändern.
Hinweis: In neueren Versionen von TeamCity sehen Sie auch die Felder Default branch und Branch specification, mit denen Sie angeben können, für welche Branches TeamCity Builds erstellen soll. Diese können Sie vorerst ignorieren.
Nachdem Sie Proceed angeklickt haben, durchsucht TeamCity automatisch Ihr Repository nach unterstützten Technologien, in diesem Fall Python.
Wenn TeamCity eine .py-Datei in Ihrem Repository erkennt, schlägt es automatisch einen oder mehrere Build-Schritte für Ihr Projekt vor. Für das in diesem Tutorial verwendete Repository würden diese automatisch erkannten Build-Schritte die Dateien main.py oder setup.py ausführen – dies ist nicht unbedingt das, was Sie wollen.
Vielmehr wäre es sinnvoll, die folgenden Build-Schritte standardmäßig zu Ihrem Python-Projekt hinzuzufügen:
Fügen wir also statt der automatisch erkannten Build-Schritte diese beiden Schritte zu Ihrem Projekt hinzu.
Als Erstes fügen Sie den Schritt Flake8 Linting zu Ihrem TeamCity-Projekt hinzu.
Wenn der Build-Schritt erfolgreich erstellt wurde, sehen Sie den folgenden Dialog:
Als Nächstes fügen Sie einen PyTest-Schritt zu Ihrem Projekt hinzu.
Sie können jetzt Ihre ersten Builds ausführen.
Hinweis: Wenn Sie TeamCity Cloud verwenden, kann es einige Minuten dauern, bis ein Build-Agent verfügbar ist. Während dieser Zeit wartet Ihr Build in der Warteschlange, bis er von einem verfügbaren Agent angenommen wird.
Wenn Sie TeamCity On-Premises mit lokalen Build-Agents verwenden, wird Ihr Build sofort gestartet.
Sobald Ihr Build gestartet wurde, werden Sie zur Übersichtsseite des Builds weitergeleitet. Dort werden auf dem Build Log-Tab Echtzeitdaten zu Ihrem Build angezeigt.
Nachdem der Build ausgeführt wurde, werden Sie zur Übersichtsseite des Builds weitergeleitet. Auf dieser Übersichtsseite können Sie sich die Testergebnisse und Inspektionen oder das komplette Buildprotokoll ansehen.
Nachdem Ihr Python-Repository nun mit TeamCity verbunden ist, können Sie die Entwicklung fortsetzen und Ihren Code in das Repository übertragen.
Standardmäßig überprüft TeamCity den main-Branch Ihres VCS-Repositorys alle 60 Sekunden auf eingehende Änderungen und löst einen (kombinierten) Build für alle erkannten Commits aus.
Wenn Sie für Änderungen in jedem Branch Ihres Repositorys – nicht nur im main-Branch – einen Build auslösen möchten, fügen Sie in Ihren VCS-Root-Einstellungen eine Branch-Spezifikation mit einem Platzhalter hinzu. Beachten Sie, dass die VCS-Einstellungen für das TeamCity-Projekt und nicht für eine einzelne Build-Konfiguration gelten. Daher werden alle Änderungen, die Sie vornehmen, auf alle Build-Konfigurationen angewendet, die denselben VCS-Root verwenden.
Beispielhafte Branch-Spezifikationen:
+:refs/heads/*
– TeamCity überprüft alle Branches Ihrer Projekte auf Änderungen, überprüft jedoch keine Pull-Requests auf Plattformen wie GitHub, da diese mit refs/pull/*
übereinstimmen. +:*
– TeamCity sucht nach beliebigen eingehenden Änderungen in beliebigen Branches. TeamCity überwacht jetzt alle Branches, die Ihrer Branch-Spezifikation entsprechen und in Ihr Repository gepusht werden. Bei eingehenden Änderungen wird ein entsprechender Build ausgeführt.
Wenn Sie möchten, dass TeamCity für Pull-Requests, die an Ihr Repository gesendet werden, automatisch Builds erstellt, können Sie das Build-Feature Pull Requests zu Ihrer Build-Konfiguration hinzufügen.
Hinweis: Das Build-Feature Pull Requests erweitert transparent die Branch-Spezifikation (siehe dazu den vorherigen Schritt). Im Fall von GitHub beispielsweise fügt das Pull-Request-Feature den (unsichtbaren) Eintrag +:refs/pull/*
zu Ihrer Branch-Spezifikation hinzu.
Bei Verwendung des Pull-Request-Features sollten die Pull-Request-Branches nicht in Ihrer allgemeinen Branch-Spezifikation enthalten sein, da ansonsten die Pull-Request-bezogenen Funktionen von TeamCity nicht verfügbar sind.
TeamCity überwacht nun die externe Plattform auf Pull-Requests und löst einen Build für diejenigen aus, die Ihren Konfigurationsregeln entsprechen.
Hinweis: In öffentlichen Repositories sollten Sie diese Funktion mit Vorsicht verwenden, da jeder schädlichen Code in das Repository pushen könnte (und diesen sollten Sie nicht kompilieren).
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. Dieses Feature aktualisiert den Status des Pull-Requests auf der jeweiligen Plattform mit den Build-Ergebnissen.
Um TeamCity so einzurichten, dass Build-Ergebnisse an GitHub gemeldet werden, müssen Sie die folgenden Schritte ausführen:
Nachdem TeamCity einen Build ausgeführt hat, können Sie jetzt direkt auf dem GitHub-Tab Pull Request sehen, ob die Änderungen einen Build-Fehler verursacht haben (grünes Häkchen).