GitHub erlaubt Vorlagen für strukturierte Ticket-Formulare

in  Verschiedenes , ,

Schon seit einiger Zeit ist es in GitHub möglich, Vorlagen für unterschiedliche Arten von Tickets zu hinterlegen. Hierbei handelt es sich um Markdown-Dateien, mit denen sich Inhalt der Beschreibung sowie weitere Angaben, wie Labels und etwaige Bearbeiter vorbelegen lassen. Für öffentliche Repositories ist nun auch ein Beta-Programm für YAML-basierte Formulardefinitionen gestartet. Diese Funktion bietet einen deutlich höheren Freiheitsgrad, indem sich mehrere Formularfelder beschreiben lassen. Wie im obigen Screenshot ersichtlich, können hiermit zum Beispiel Dropdowns/Auswahllisten verwendet und gewünschte Angaben als verpflichtend gekennzeichnet werden.

Abhängigkeiten automatisch aktualisieren mit Dependabot

in  Builds & Tests , ,

Vor knapp eineinhalb Jahren haben wir gezeigt, wie man die Aktualisierung verwendeter Drittkomponenten mit GitHub Actions automatisieren kann. Zwischenzeitlich sind wir hierbei auf den Dependabot umgestiegen. Dieses Tool wird bei GitHub schon länger zum Aufspüren und Melden von Sicherheitsproblemen verwendet. Es ist damit jedoch auch möglich, Updates zu suchen und bereitzustellen. Im Gegensatz zu dem früheren Vorgehen gibt es dabei folgende Unterschiede und Vorteile: Für jede Komponente wird ein eigener Pull Request erstellt.

Hugo-Seiten im Netzwerk entwickeln und testen

in  Builds & Tests , , , ,

Hugo ist ein Generator für statische Seiten, welcher auf der Programmiersprache Go basiert. Die Inhalte werden mit Markdown verwaltet und dynamisch in HTML umgewandelt. Dies ist für die meisten kleineren Projekte interessant, weil ausreichend und im Vergleich zu einem dynamischen Content Management System einfacher zu handhaben; zudem sind statische Seiten auch in Bezug auf Sicherheit und Performanz unschlagbar (siehe auch: Vorteile statischer Seiten). Der Build lässt sich dann z. B. mit GitHub Actions durchführen (zum Einsatz kommt hierfür z.

SensioLabs Security Checker wurde eingestellt

in  Builds & Tests , , ,

Zu den grundlegenden Aufgaben automatisierter Builds zählen unterschiedliche Prüfungen: so bietet es sich an, die Einhaltung der Coding-Styles zu überwachen, Qualitätsmetriken zu erheben und die Testabdeckung zu messen. Auch die regelmäßige Aktualisierung verwendeter Drittkomponenten kann perfekt automatisiert werden, wie wir es in diesem Beitrag für GitHub Actions gezeigt haben. Ein nützliches Werkzeug, das anhand einer composer.lock Datei etwaige Sicherheitslücken in verwendeten Vendors aufgezeigt hatte, war der SensioLabs Security Checker. Dieser hat die entsprechenden Versionen mit einer Datenbank auf security.

Zahlreiche Neuerungen und Funktionen bei GitHub

in  Verschiedenes , ,

Im Rahmen der GitHub Konferenz “Universe” wurden neue Funktionen und Verbesserungen vorgestellt. Für jeden dürfte hier etwas dabei sein. Nachfolgend die für mich wichtigsten Neuerungen in der Kurzübersicht: Das Mergen von Pull Requests kann automatisiert werden, basierend auf vordefinierten Erforderlichkeiten, wie etwa notwendige Reviews und Prüfungswerkzeuge. Mit den Discussions lässt sich nun auch jedwede, von Aufgaben/Tickets unabhängige Kommunikation, wie Support und sonstige Abstimmungen, auf der GitHub Plattform durchführen. GitHub unterstützt jetzt offiziell einen Dark Mode.

GitHub integriert Code Security Scanner

in  Builds & Tests , , ,

Im offiziellen GitHub Changelog werden regelmäßig Beiträge über unterschiedliche Neuerungen und Innovationen auf der GitHub Plattform veröffentlicht, zum Beispiel in Bezug auf Funktionen in der Oberfläche, GitHub Actions oder anderweitige Aktivitäten. Gestern erschien dort ein Artikel darüber, dass nun die Funktionalität zum Scannen von Code auf Sicherheitsprobleme allgemein verfügbar gemacht worden ist. Weitere Informationen hierzu lassen sich diesem Beitrag entnehmen. Neben der von GitHub forcierten CodeQL Analyse stehen auch alternative Analysewerkzeuge von Drittanbietern zur Integration bereit.

Symfony Services asynchron im Hintergrund aufrufen

in  Zikula Apps , , , , ,

Oftmals greift man in Symfony-Projekten auf CLI-Kommandos mit Hilfe der Symfony Console-Komponente zurück, um länger laufende Prozesse außerhalb des Webservers durchzuführen. In komplexeren Vorhaben gibt es weitere Ansätze, wie etwa eine Job Queue oder die noch relativ junge Symfony Messenger-Komponente. Diese haben gemeinsam, dass sie eine bestimmte Struktur voraussetzen. Für die Umstellung von Legacy-Code, in dem selbstgeschriebene Jobs mit ReactPHP Event-Loops zum Einsatz kommen, haben wir vorerst einen anderen Weg gewählt, um diese Worker in Einklang mit Symfony zu bringen.

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

in  Builds & Tests , , , , ,

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 , , , , ,

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 , , ,

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.