Für manche Testszenarien muss auch ein Dateidownload mit getestet werden, z.B. um die resultierende Datei auf Korrektheit zu prüfen. Für Ende-zu-Ende Tests gibt es diverse Werkzeuge, eins davon ist das von Google entwickelte Puppeteer. Mit Puppeteer lässt sich aktuell der Chrome Browser fernsteuern, eine Erweiterung auf Mozilla Firefox ist ebenfalls in Arbeit.

In diesem Beitrag wird gezeigt, wie mit Docker und Puppeteer ein entsprechendes Testszenario umgesetzt werden kann.

Im letzten Artikel haben wir ein macOS-Environment für NativeScript provisioniert. Nun wollen wir dieses System nutzen und als Runner in Gitlab registrieren, um dort eine CI-Pipeline für ein NativeScript-Projekt zu erstellen.

In diesem Kubernetes Beitrag geht es darum, eine CI Pipeline auf Kubernetes Infrastruktur aufzusetzen. Wie bereits in den vorherigen Kubernetes Beiträgen soll auch hier ein Augenmerk auf dem Support der ARM Plattform gelegt werden. Leider trotz der zunehmenden Verbreitung von ARM im Serverumfeld noch immer nicht selbstverständlich, dass Multi-Arch Images bereitgestellt werden.

Um Anwendungen erfolgreich bauen zu können, ist - je nach Anwendung - ein hoher Aufwand in die Einrichtung der Umgebung zu investieren. Beispielsweise für ein Android-Projekt muss Java installiert sein, es werden die Android-Tools mit dem Android-SDK benötigt und der Build muss passend konfiguriert werden. Dieses Setup wird aber nicht nur auf den Entwickler-Rechnern benötigt, auch die Countinuous-Integration-Umgebung des Buildservers muss entsprechende Werkzeuge bereitstellen. Um Reproduzierbarkeit zu gewährleisten, sollte sichergestellt sein, dass in allen diesen Umgebungen die gleichen Versionen der Tools genutzt werden.

In diesem Artikel werden wir uns damit beschäftigen, wie auf einfachem Wege eine zur Entwicklung von Android-Projekten geeignete Umgebung mit Hilfe von Docker erstellt werden kann. Am Beispiel von Gitlab-CI wird der Einsatz des entsprechenden Docker-Containers in einer CI-Umgebung gezeigt.