GitHub Actions - Eine Aktion zum Bauen und Testen von Zikula-Modulen

in  Builds & Tests , , , , ,

GitHub Actions - Eine Aktion zum Bauen und Testen von Zikula-Modulen
Vor ein paar Wochen haben wir unsere generator-action vorgestellt, welche die einfache Generierung von Zikula-Erweiterungen mit dem Standalone Generator von ModuleStudio erlaubt. Diese Action wird als Docker Image bereitgestellt und kann auch losgelöst von GitHub Actions verwendet werden. Die zikula-action Analog dazu steht auch eine weitere GitHub Action zur Verfügung: die zikula-action. Dieses Docker Image basiert auf der ebenfalls bereits vorgestellten phpqa-Toolbox und hat somit Zugriff auf zahlreiche Tools rund um Analyse, Tests und Qualitätssicherung.

GitHub Actions - Eine Aktion zum Generieren von Zikula-Modulen

in  Builds & Tests , , , , ,

GitHub Actions - Eine Aktion zum Generieren von Zikula-Modulen
Der Standalone-Generator ModuleStudio bietet einen Standalone-Generator, mit dem sich jederzeit eine Anwendung über die Kommandozeile generieren lässt. Einige allgemeine Informationen hierzu sind der Dokumentation zu entnehmen. Ein simples Beispiel für die Nutzung findet sich ferner in diesem Artikel. Eine Besonderheit hierbei ist, dass die verwendete jar-Datei bei jedem Build des Generators aktualisiert wird. Es handelt sich also immer um den aktuellen Git-Stand. Damit bietet es sich an, den Standalone-Generator zur kontinuierlichen Integration zu verwenden.

GitHub Actions - Programmatische Trigger, Build Pipelines, Dashboard

in  Builds & Tests , , ,

GitHub Actions - Programmatische Trigger, Build Pipelines, Dashboard
In diesem Beitrag geht es darum, mehrere und unterschiedliche Build Jobs miteinander zu verknüpfen. Je größer eine Build Infrastruktur wird, desto häufiger wird man mit solchen Anforderungen konfrontiert, möchte man nicht einen riesigen Monolithen bauen. Bei ModuleStudio gibt es beispielsweise mehrere Komponenten, die jeweils komplett unabhängig gebaut und getestet werden. Dennoch muß es für Integrationstests und zum Bauen der fertigen Produkte möglich sein, dass eine neue Version einer Komponente die Jobs für weitere Komponenten startet und somit eine Ausführung deren Workflows nach sich zieht.

GitHub Actions - Java-Projekte bauen und testen

in  Builds & Tests , , ,

GitHub Actions - Java-Projekte bauen und testen
Nachdem im letzten Artikel gezeigt wurde, mit welchen Mitteln sich in GitHub Actions Projekte auf Basis von PHP verarbeiten lassen, schauen wir nun auch einmal kurz in die Java-Welt. Werkzeuge für das Build-Management In Java ist es gang und gebe, die Builds mit spezifischen Tools zu beschreiben, hier sind als gängigste Beispiele Maven, Gradle oder auch Ant zu nennen. Das ist insoweit hilfreich, als dass viele Abhängigkeiten darüber verwaltet werden.

GitHub Actions - PHP-Projekte bauen und testen

in  Builds & Tests , , ,

GitHub Actions - PHP-Projekte bauen und testen
Eine Aktion zur PHP-Einrichtung Für die wichtigsten Punkte, die notwendig sind, um ein auf PHP basierendes Projekt zu testen, gibt es die Action setup-php. Diese bietet unter anderem folgende Möglichkeiten: unterschiedliche PHP-Versionen verwenden PHP-Extensions einrichten PHP-Konfigurationen vornehmen zusätzliche, häufig verwendete Tools installieren Diese Aktion sollte für allgemeine Anwendungen keine Wünsche offen lassen. Wir verwenden diese Aktion seit einigen Monaten in mehreren Repositories ohne jegliche Probleme. Weitergehende Möglichkeiten Auch Matrix-Builds sind möglich: hiermit lässt sich ein Workflow für mehrere Betriebssysteme und/oder PHP-Versionen ausführen.

GitHub Actions - Abhängigkeiten automatisch aktualisieren

in  Builds & Tests , ,

GitHub Actions - Abhängigkeiten automatisch aktualisieren
Nach der allgemeinen Einführung in GitHub Actions kommen wir nun zu dem ersten Anwendungsfall, der in vielen Projekten angewendet werden kann. Fast jedes Softwareprojekt bedient sich heutzutage zusätzlicher Drittkomponenten. Diese müssen regelmäßig geprüft und auf Stand gehalten werden, um sowohl Fehlerkorrekturen als auch neue Funktionen zu erhalten. In den meisten Programmiersprachen und Umgebungen kommen Paketmanager zum Einsatz, mit denen diese Abhängigkeiten verwaltet und gepflegt werden. Das ist eine geeignete Voraussetzung dafür, die Updates zu automatisieren.

GitHub Actions - Vorstellung und erster Einstieg

in  Builds & Tests , ,

GitHub Actions - Vorstellung und erster Einstieg
Mit GitHub Actions ist es möglich, beliebige Workflows in einem GitHub Repository zu definieren und dort auch automatisch ausführen zu lassen. Das können Builds und Tests zur kontinuierlichen Integration sein, aber auch völlig unabhängige Prozesse, zum Beispiel zur regelmäßigen Prüfung bestimmter Anforderungen. In den letzten Wochen und Monaten haben wir mehrere Dutzend Workflows mit GitHub Actions abgebildet und entsprechende Erfahrungen gesammelt. Im Rahmen einer kleinen Artikelserie werden wir einige der vielfältigen Möglichkeiten vorstellen, die sich mit GitHub Actions auftun.

Automatisierte Tests - ein Zwischenstand

in  Builds & Tests , , ,

Automatisierte Tests - ein Zwischenstand
Seit dem kürzlich angekündigten Start der Testautomatisierung von ModuleStudio ist bereits eine Menge geschehen. So gibt es knapp 1.000 Tests für die DSL, darunter vorwiegend für UI-unabhängige Komponenten, wie den Parser, den Serialisierer, den Formattierer und die Validierungsregeln. Hier haben wir eine Testabdeckung von etwa 95% erreicht und konnten einige Fehler in der Validierungsschicht beheben. Auch der Generator wird bereits mit einer Abdeckung von über 90% getestet. Hier ging es bislang allerdings vorwiegend darum, möglichst viele Varianzen zu durchlaufen, um zum Beispiel Null Pointer Exceptions zu verhindern.

Ran an die Tests!

in  Builds & Tests , ,

Ran an die Tests!
Schon ewig geplant, aber lange schmählich vernachlässigt, habe ich bei ModuleStudio die automatisierten Tests. Zwar ist schon seit Längerem die Infrastruktur dahingehend ausgerichtet, was beispielsweise die Git-Struktur und die Jenkins-Pipelines anbelangt, allerdings bringt das relativ wenig, wenn es fast nur Dummy-Tests ohne jeglichen Inhalt gibt. Da ModuleStudio 1.1.0 kürzlich veröffentlicht wurde, konnten danach in der Entwicklungsversion 1.2.0 einige Altlasten entfernt werden. Da hat es sich im Hinblick auf Timing und Ausgangslage angeboten, endlich zu starten.

Erneuertes Build-System für ModuleStudio

in  Builds & Tests , , ,

Erneuertes Build-System für ModuleStudio
Die Komponenten von ModuleStudio werden nun mit anderen Technologien gebaut. Statt Buckminster wird jetzt das Maven-basierte Tycho eingesetzt. Die Jenkins-Jobs wurden auf Pipelines umgestellt und unterstützen somit nun mehrere Branches. Tycho für Features in mehreren Repositories Im ersten Schritt habe ich daran gearbeitet, die Builds lokal mit Tycho zum Laufen zu kriegen. Eine Herausforderung dabei war es, die Builds für alle Komponenten, die in unterschiedlichen Git-Repositories liegen, mit möglichst wenig Redundanz zu beschreiben.