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.
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.
Schon seit einiger Zeit werden im GitHub-Repository des Zikula Core die Dinge dokumentiert, die zusätzlich zu den Handbüchern von Symfony, Doctrine, Twig, Bootstrap usw. zu beachten sind. Nun wurde die Struktur dieser Dokumente jedoch überarbeitet und in eine Gesamtsicht gekleidet.
Themenorientiert Frühere Ansätze von Handbüchern und Doku-Sammlungen haben oft versucht, unterschiedliche Bereiche für Entwickler und Administratoren aufzubauen. Dies hatten wir wieder versucht, sind dann aber zu der Erkenntnis gelangt, dass es zu viele Überschneidungen gibt und das Ganze vor allem unübersichtlich wird.
Nachdem wir bereits in einigen Artikeln zu Zikula 3 die Änderungen unter der Haube, umfangreiche Modernisierungen, Möglichkeiten für dynamische Formulare und Neuerungen rund um Übersetzungen vorgestellt hatten, sollen nun einige weitere der neuen Features und Änderungen vorgestellt werden.
Module + Themes = Extensions Die Verwaltung von Modulen und Themes läuft nun unter einem gemeinsamen Dach: Extensions.
Hintergrund ist unter anderem, dass Themes ebenso wie Module eigenständige Symfony-Bundles sind und mehr als nur Layout können.
Nachdem zwischen den Jahren der komplette Unterbau von Zikula 3 auf Stand gebracht worden ist, hat sich der nächste Sprint dem Übersetzungssystem gewidmet. In diesem Beitrag wird kurz dargestellt, welche neuen Funktionen eingebracht worden sind:
Es gibt eine verbesserte Unterstützung für Regionen und Sprachvarianten (z. B. de_DE und de_CH neben de). Die automatische Erkennung zusätzlich vorhandener Sprachpakete wurde verbessert. Die Konfiguration für die Übersetzung von Modulen und Themes wird automatisch auf Stand gehalten.
Im Rahmen des letzten Sprints wurde der Unterbau von Zikula 3 auf den neuesten technischen Stand gebracht. Im Folgenden wird kurz zusammengefasst, was hierbei genau passiert ist.
Twig 3 Als erstes sollte die Template-Engine Twig auf die Version 3 gebracht werden. Dies versprach anfangs eine sehr übersichtliche Sache zu werden. Allerdings gab es dann doch noch einige weitere Aspekte zu beachten:
Da die templating-Komponente in Symfony 5 entfernt wird, müssen Pfade zu Templates nun der Namespace-Notation folgen.
Im letzten Trello-Tipp ging es um Vorlagen, mit denen unregelmäßig wiederkehrende Aufgaben unterstützt werden können. Oftmals gibt es aber auch Tätigkeiten, die tatsächlich in regelmäßigen Intervallen durchgeführt werden müssen. Allerdings sind sie nicht unbedingt geeignet für einen Kalender 📆 , weil sie nicht punktgenau an einem bestimmten Tag stattfinden - es geht hier nicht um Termine, sondern um Aufgaben. Um solche Dinge abzubilden, verwenden wir in Trello das Power-Up “Card Repeater”.