Get the MOST

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.

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.

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.

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.

Das allgemeine Vorgehen für Java-Projekte sieht daher wie folgt aus:

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.

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.

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.

Rund um den ursprünglich von GitHub ins Leben gerufene Editor Atom hat sich mittlerweile ein ansehnliches Ökosystem entwickelt. So existieren aktuell bereits knapp 8.000 Erweiterungen für alle möglichen Einsatzzwecke und über 2.500 Themes zur Veränderung der Darstellung. Atom gilt als äußerst anpassbarer Editor, da das Konzept der Packages direkt im Kern verankert ist.

Zu den subjektiv für mich vielversprechendsten Funktionen gehören die nahtlose Einbindung von Git-Workflows und GitHub sowie das sogenannte Teletype, welches die simultane Arbeit mit mehreren Entwicklern ermöglicht - ähnlich wie man es von Google Docs kennt.

Craig Heydenburg hat in den letzten Wochen die Benutzerverwaltung (Users-Modul) im Zikula-Core zur Unterstützung von Twig und Symfony Forms überarbeitet. Doch damit nicht genug: er hat zudem jegliche Funktionalität in Bezug auf die Registrierung und die Anmeldung von Benutzern in ein eigenes Systemmodul namens ZAuth separiert, welches ebenfalls im Core enthalten ist.

Als Teil dieser Auslagerung wurden die Schnittstellen zur Implementierung von Authentifizierungsmethoden generalüberholt. Damit wird es nun einfacher, andere Wege zur Erstellung neuer Benutzer und zum Login derselben anzubieten. Ein Beispiel hierfür ist das OAuth-Modul, mit dem Anmeldungen basierend auf dem OAuth-Standard durchgeführt werden können. Aktuell werden darüber bereits die Anbieter Github und Google unterstützt. Damit kann man sich ganz einfach mit einem bestehenden Github- oder Google-Konto auf Zikula-Seiten, die das Modul installiert haben, anmelden.

Gegenwärtig beschäftige ich mich mit zwei interessanten Punkten in Bezug auf Jenkins. Die neu gestaltete Website bietet dazu einen guten Einstiegspunkt.

Der erste Punkt dreht sich darum, Jenkins besser mit GitHub zu verzahnen.

• Hier steht insbesondere eine engere Integration des Build Status im Raum. Die Nutzung von Service Hooks erlaubt es, einen Build via Push zu starten, was sowohl schneller als auch effizienter als das zeitbasierte Polling des Git-Repositories seitens Jenkins abläuft.
• Durch die Commit Status API kann der Erfolg oder Fehler eines Builds zu einem Commit auf GitHub reflektiert werden.
• Der aktuelle Build-Zustand des Repositories sollte auf GitHub angezeigt werden.
• Auch Pull Requests sollten ebenso wie der Hauptbranch gebaut werden.

Der zweite Bereich behandelt Pipelines, mit denen sich der Workflow eines Jobs flexibel orchestrieren lässt.