Builds und Tests für Python

1. Klicken Sie in der oberen rechten Ecke der TeamCity-Seite auf Administration.
   
2. Klicken Sie auf + Create Project und wählen Sie den Tab From a repository URL aus. In the Repository URL field, enter your repository, for example: https://github.com/marcobehlerjetbrains/teamcity-python.git. TeamCity kommt von Haus aus mit allen gängigen Versionierungssystemen zurecht: Git, Subversion, Mercurial, Perforce und TFS (TeamCity Cloud + lokale Installation). Die Unterstützung für CVS, StarTeam und Visual SourceSafe ist nur in lokalen TeamCity-Installationen verfügbar.
3. Wenn Ihr Repository eine Authentifizierung erfordert, geben Sie Ihren Benutzernamen und Ihr Passwort oder Ihren Zugriffstoken ein.
4. Klicken Sie auf Proceed.

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.

• TeamCity schlägt einen Standard-Projektnamen vor, Sie können Ihrem Projekt jedoch bei Bedarf einen geeigneteren Namen geben.
• TeamCity schlägt auch einen Standardnamen für die Build-Konfiguration vor. Sie können hier die Standardeinstellung beibehalten. Bei Bedarf können Sie den Namen auch später ändern. (Jedes TeamCity-Projekt besteht aus mindestens einer Build-Konfiguration, die alle Schritte enthält, die zum Kompilieren Ihres Projekts erforderlich sind. Die Build-Konfigurationen von TeamCity werden in anderen CI-Systemen oft als Jobs bezeichnet.)
• Klicken Sie auf Proceed.

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:

1. einen Build-Schritt Linting, der Flake8 oder PyLint ausführt
2. einen Build-Schritt Testing, der PyTest oder UnitTest ausführt

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.

1. Klicken Sie auf Build Steps, um die automatisch erkannten Build-Schritte zu verwerfen.
2. Klicken Sie auf Add Build Step und wählen Sie Runner type: Python aus, um einen Build-Schritt hinzuzufügen, der Python-Builds erstellen kann.
3. Wählen Sie Command: Flake8, da in diesem Python-Projekt eine Flake8-Abhängigkeit für Linting eingerichtet ist. Würde das Projekt Pylint fürs Linting verwenden, würden Sie hier Pylint auswählen.
4. Im Feld Script or module arguments können Sie das Verzeichnis angeben, in dem das Linting stattfinden soll. Stellen Sie „src/anewtodolist“ ein, wenn Sie mit dem Python-Repository aus diesem Tutorial arbeiten. Sie können das Feld auch leer lassen, um das gesamte Projekt zu linten.
5. Optional: Wählen Sie eine andere Python-Version aus, wenn Ihr Projekt noch Python 2.x verwendet.
6. Umgebungstool: Dieses Projekt verwendet Virtualenv für alle benötigten Abhängigkeiten wie Flake8 und PyTest. Aktivieren Sie die Virtualenv-Unterstützung, indem Sie es als Umgebungstool auswählen.
7. Klicken Sie auf Save.

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.

1. (Optional) Wenn Sie sich nicht auf der Seite Build Steps Overview befinden, klicken Sie auf Build Steps, um die automatisch erkannten Build-Schritte zu verwerfen.
2. Klicken Sie auf Add Build Step und wählen Sie Runner type: Python aus, um einen Build-Schritt hinzuzufügen, der Python-Builds erstellen kann.
3. Wählen Sie Command: Pytest, da in diesem Python-Projekt eine Pytest-Abhängigkeit für Tests eingerichtet ist. Würde das Projekt UnitTest zum Testen verwenden, würden Sie hier UnitTest auswählen.
4. Optional: Im Feld Script or module arguments können Sie das Verzeichnis angeben, das getestet werden soll. Wenn Ihre Tests im Ordner /tests untergebracht sind, können Sie das Feld leer lassen, da der Python-Runner diesen Ordner automatisch erkennt.
5. Optional: Wählen Sie eine andere Python-Version aus, wenn Ihr Projekt noch Python 2.x verwendet.
6. Umgebungstool: Dieses Projekt verwendet Virtualenv für alle benötigten Abhängigkeiten wie Flake8 und PyTest. Aktivieren Sie die Virtualenv-Unterstützung, indem Sie es als Umgebungstool auswählen.
7. Klicken Sie auf Save.

Sie können jetzt Ihre ersten Builds ausführen.

1. Klicken Sie in der oberen rechten Ecke des Fensters auf Run (siehe nachstehende Abbildung).
2. Warten Sie, bis der Buildvorgang abgeschlossen ist.

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.

Builds für Branches erstellen

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.

1. Klicken Sie auf der Übersichtsseite des Projekts auf Edit Project. Alternativ, wenn die Build-Konfiguration Build geöffnet ist, klicken Sie auf Edit Configuration.
2. Navigieren Sie zu VCS Roots (Versionierungssysteme) und bearbeiten Sie Ihren VCS-Root.
3. Füllen Sie das Eingabefeld Branch Specification aus und klicken Sie auf Save. Wenn Sie das Eingabefeld Branch Specification nicht sehen können, klicken Sie zuerst auf Show Advanced.

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.
• Ihre eigene Branch-Spezifikation.

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.

Builds nach Pull-Requests

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.

1. Öffnen Sie Ihre Build-Konfiguration und klicken Sie auf Edit Configuration.
2. Navigieren Sie zu Build Features und klicken Sie auf Add Build Feature. Wenn Sie den Link Build Features nicht sehen können, klicken Sie auf Show More.
3. Wählen Sie Pull Requests aus der Dropdown-Liste und wählen Sie Ihr Repository sowie den Repository-Anbieter (GitHub, GitLab usw.) aus.
4. Aktivieren Sie optional die Pull-Request-Filterung nach Autor oder Branch-Name.

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).

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. 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:

1. Öffnen Sie Ihre Build-Konfiguration und klicken Sie auf Edit Configuration.
2. Navigieren Sie zu Build Features und klicken Sie auf Add Build Feature.
3. Wählen Sie Commit Status Publisher aus der Dropdown-Liste und wählen Sie Ihr Repository sowie einen Publisher (GitHub, GitLab usw.) aus.
4. Geben Sie einen Zugriffstoken mit ausreichenden Rechten zum Veröffentlichen von Commit-Status-Informationen an.
5. Klicken Sie auf Save.

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).