Blog

Git-Hooks mit Perl

06.01.2021 // Renée Bäcker

Git ist eine weit verbreitete Software zur Versionsverwaltung. Wir nutzen Git seit vielen Jahren, um unseren Perl-Code zu verwalten. Soll im Git-Workflow etwas erzwungen werden, kommen sogenannte Git-Hooks zum Einsatz.

Wenn Code committet oder zum Server ge*pusht* wird, werden diese Hooks ausgeführt. Das sind Skripte, die automatisch bei diesen Events ausgeführt werden. Eine Liste mit den ganzen Events ist im Git-Handbuch zu finden. Man unterscheidet die Hooks danach, ob sie auf dem Client oder auf dem Server ausgeführt werden.

Git ist bei den Hooks sehr flexibel und die Hooks können in allen möglichen Programmiersprachen umgesetzt werden – auch in Perl. Hier soll ein Beispiel gezeigt werden, wie ein solcher Hook aussehen kann. Ziel ist es, bei einem vorhandenen cpanfile die darin genannten Perl-Module zu prüfen, ob sie in CPAN::Audit genannt sind. Damit soll einfach sichergestellt werden, dass schon bei der Entwicklung auf Sicherheitslücken in eingesetzten Perl-Modulen hingewiesen wird.

Client-Hooks

Im ersten Schritt schreiben wir ein Skript, das auf dem Client ausgeführt wird. Die Hooks liegen im Ordner .git/hook. Dort erstellen wir eine Datei mit dem Namen des Events auf das wir reagieren wollen. In diesem Fall möchten wir die Prüfung nach jedem Commit machen. Daher erstellen wir die Datei post-commit und machen diese ausführbar.

In diesem Fall werden keine Paramter übergeben. Wir werten mit CPANfile::Parse::PPI die Datei cpanfile aus und prüfen dann die Module mittels CPAN::Audit:

#!/usr/bin/perl

use v5.24;
  
use strict;
use warnings;

use File::Basename;
use File::Spec;
use CPAN::Audit::DB;
use CPAN::Audit::Query;
use CPANfile::Parse::PPI;

my $basedir = File::Spec->catdir( dirname(__FILE__), '..','..');
my $file    = File::Spec->catfile( $basedir, qw/cpanfile/ );
my $db      = CPAN::Audit::DB->db;
my $query   = CPAN::Audit::Query->new( db => $db );

my $cpanfile = CPANfile::Parse::PPI->new( $file );

MODULE:
for my $module ( $cpanfile->modules->@* ) {
    my $distname = $db->{module2dist}->{$module->{name}};

    next MODULE if !$distname;

    my @advisories = $query->advisories_for( $distname, $module->{version} );

    next MODULE if !@advisories;

    print sprintf "There are advisories for %s %s\n", $module->{name}, $module->{version};
}

Angenommen wir haben folgendes cpanfile:

requires 'Mojolicious' => 8.42;
requires 'Archive::Zip' => 0;

Dann kommt bei einem Commit diese Meldung:

d9e71c16-f5db-4ffd-8563-45edab515448.png

So kann schon während der Entwicklung sichergestellt werden, dass man auf Module aufmerksam gemacht wird, für die Sicherheitslücken bekannt sind.

Dieser Git-Hook ist ganz praktisch, hat aber – wie alle clientseitigen Hooks – das Problem, dass sie bei einem git clone nicht mitgeklont werden. Die Hooks müssen also auf anderem Wege verteilt werden. Und es ist nicht sichergestellt, dass alle Hooks in den Arbeitskopien auch tatsächlich angewendet werden.

Sollen also gewisse Richtlinien erzwungen werden, ist es notwendig die Hooks auf dem Server einzurichten – mit einem passenden Event.

Server-Hooks

Soll der gleiche Hook wie auf dem Server nach einem push ausgeführt werden, muss das Skript direkt auf dem Server abgelegt werden. Testen können wir das, indem ein neues Git-Repository erstellt wird:

mkdir TestRepository
cd TestRepository
git init --bare

Da wir das init mit dem Parameter --bare aufgerufen haben, werden in dem Repository keine Dateien mit Code zu finden sein. Die Verzeichnisstruktur ist auch eine andere. Hier haben wir direkt die Struktur, wie sie in der Arbeitskopie im Verzeichnis .git/ zu finden ist.

Der Hook von oben muss in das Verzeichnis hooks/ kopiert werden, aber mit einem neuen Namen: post-receive. Das ist das Event, das nach einem push ausgelöst wird. Es verhindert also nicht, dass die Entwickler*innen Code auf den Server schieben, aber man kann beliebige Meldungen ausgeben. Soll ein push erfolglos sein, wenn ein Modul mit Sicherheitslücken im cpanfile gelistet ist, müssen wir den Hook von oben als pre-receive speichern.

Eine weitere Änderung ist notwendig, da – wie oben geschrieben – keine Dateien mit Code im Repository zu finden sind. Inhalte der Dateien lassen sich mit git show auslesen, daher sieht hier der entsprechende Teil des Hooks folgendermaßen aus:

my @args = <>;
chomp @args;

my $branch = (split /\s+/, $args[0])[-1];
my $required = qx{git show $branch:cpanfile};
my $db       = CPAN::Audit::DB->db;
my $query    = CPAN::Audit::Query->new( db => $db );

my $cpanfile = CPANfile::Parse::PPI->new( \$required );

Dieser Hook bekommt die Parameter alter Commithash, neuer Commithash und Branch über STDIN. Hier wird also immer das cpanfile des Branchs ausgelesen, der zum Server geschickt wird.

Wird jetzt ein push der Änderungen gemacht, meldet sich der Server mit

95cc815c-aec1-42ca-a65e-d39f7f38c49f.png

Das was bisher gezeigt wurde, gilt für git pur. Wir verwenden zur Verwaltung unserer Git-Repositories Gitlab. Neben den klassischen Git-Features nutzen wir hier vor allem die Continuous Integration Features.

Mit Gitlab sieht der Einsatz der serverseitigen Hooks etwas anders aus: Zuerst brauchen wir den Pfad zum (bereits existierenden) Repository. Dazu öffnen wir den Adminbereich und schauen uns das gewünschte Projekt/Repository an. Dort finden wir einen Eintrag Gitaly relative path: **@hashed/2c/69/2c69\[...\]bde.git**. Wir müssen auf dem Server in das Verzeichnis von Gitaly, z.B. /srv/gitlab/data/git-data/repositories/. Danach in das Verzeichnis wechseln, das im Adminbereich von Gitlab ausgelesen wurde.

Gitlab hat den oben gezeigten hooks-Ordner für etwas anderes benutzt. Aus diesem Grund dürfen die Hooks aber nicht in das Verzeichnis hooks/, sondern es muss ein Verzeichnis custom_hooks/ angelegt werden. Dort wird der Hook gespeichert. Der Rest bleibt wie gezeigt.

Quellen:


Permalink:

Teaser: Gitlab und Perl

28.12.2020 // Gregor Goldbach

Gitlab bietet viel Funktionalität, die für Perl-Projekte sinnvoll genutzt werden kann. Unsere Schulung soll am praktischen Beispiel einer kleinen CPAN-Distribution einen Einblick in die Möglichkeiten bieten.

Zunächst geben wir einen kurzen Überblick über »Gitlab an sich«. Dafür verwalten wir die Quellen eines Beispielprojektes innerhalb von Gitlab. Die Metadaten dieser Beispieldistribution pflegen wir innerhalb der Distribution in einer Form, die dann später von metaCPAN ausgewertet wird.

Da das weit verbreitete Github sich mit seinen »pull requests« (PRs) von den »merge requests« (MRs) Gitlabs leicht unterscheidet, gehen hierauf im Anschluss etwas ausführlicher ein.

Wir zeigen außerdem, wie sich die Entwicklungsaufgaben mit Tickets abbilden lassen und wie die Arbeitsabläufe über Labels übersichtlich an Boards dargestellt werden können.

Entwicklerinnen können ihr Projekt in einem Wiki dokumentieren, das als eigenes Git-Repository geführt wird.

Der für Entwickler vermutlich interessanteste Teil nimmt den größten Raum ein: Die CI-Stufe von Gitlab. Was bedeutet »continuous integration« im Zusammenhang mit Gitlab? Wie konfigurieren Team-Mitglieder die CI ihres Projekts? Wir konfigurieren die CI-Stufe für unser Beispielprojekt, das auf Dist::Zilla basiert, und lassen die automatisierten Tests nach jedem Commit in Gitlab durchlaufen.

Neben Grundkenntnissen in Git und Perl benötigen die Teilnehmer einen eigenen Laptop. Diese Schulung ermöglicht den Teilnehmern, Perl-Projekte in Gitlab zu bearbeiten und beliebige Befehle in Docker-Images durch Gitlabs CI-Stufe ausführen zu lassen.

Gitlab und Perl bieten wir in einer kurzen GPW-Fassung und einer längeren Fassung.

Sie haben Interesse an der Schulung? Dann melden Sie sich bei uns.


Permalink:

Perl-Schulungen 2021

07.12.2020 // Renée Bäcker

Nachdem wir uns das Jahr 2020 Zeit genommen haben, um die Perl-Academy etwas umzubauen (mit neuem Design, der Einführung dieses Blogs, mit Gregor als zusätzlicher Trainer, ...), wollen wir heute unseren Plan für 2021 vorstellen.

Wir werden wenige feste Termine für offene Schulungen haben. Wir wollen mehr Firmenschulungen anbieten und offene Schulungen zusätzlich planen, wenn sich Interessenten melden.

Unsere Schulungsthemen werden wir am Lebenszyklus einer Anwendung ausrichten. Auch in agilen Umgebungen hat man immer wieder den Lebenszyklus in klein. Momentan haben wir vier Themen geplant:

Einsteigen werden wir mit User Story Mapping. Kein originäres Perl-Thema, aber eine ganz praktische Vorgehensweise, um eine Anwendung aus Sicht des Benutzers zu planen.

Die mit User Story Mapping geplante Software werden wir mit Mojolicious umsetzen. Dabei werden wir mit einer kleinen Version anfangen um die Grundlagen von Mojolicious kennenzulernen. Anschließend werden wir die Anwendung wachsen lassen, um die weitergehenden Fähigkeiten von Mojolicious nutzen zu können.

Natürlich muss man nicht erst die User-Story-Mapping Schulung besucht haben, um an der Mojolicious-Schulung teilzunehmen.

Das Thema Sicherheit in Perl-Anwendungen spielt natürlich auch bei Mojolicious-Anwendungen ein Thema. Wir haben eine eigene Schulung daraus gemacht, um dem Ganzen genügend Raum zu geben und uns nicht auf Mojolicious zu beschränken.

Als viertes Thema bieten wir Gitlab und Perl an. Die Versionsverwaltung begleitet die Anwendung ein Leben lang. Wir zeigen, was man abseits der reinen Versionsverwaltung mit Gitlab machen kann – von Continuous Integration bis zum Ausliefern der Anwendung.

Interesse an einer der Schulungen? Dann melden Sie sich bei uns!


Permalink:

Perl-Schulungen vor dem Deutschen Perl-/Raku-Workshop 2021 in Leipzig

10.11.2020 // Renée Bäcker

Auch während der aktuell hohen Infektionszahlen in der Corona-Pandemie schauen wir nach vorne. Nach aktuellem Stand findet der Deutsche Perl-/Raku-Workshop 2021 Ende März in Leipzig statt (sollte die Corona-Situation das nicht hergeben, wird da mit Sicherheit reagiert).

Wir wollen den Workshop zum Anlass nehmen, am Tag vorher (23. März 2021) zwei Halbtagesschulungen anzubieten:

Den Tag beginnen wird Gregor mit Gitlab und Perl. In dem Kurs, der von 08:00 Uhr bis 12:00 Uhr stattfinden wird, geht es um die Entwicklung von Perl-Distributionen mit Hilfe der Plattform Gitlab. Gregor wird anhand einer CPAN-Distribution kurz die hierfür relevanten integrierten Komponenten der Plattform vorstellen und insbesondere auf die continuous integration eingehen. Ein Schwerpunkt liegt hier auf der schnellen Rückmeldung an Entwickler nach einem Commit.

Am Nachmittag (13:30 Uhr bis 17:30 Uhr) geht es dann um REST-APIs mit Mojolicious. Ich werde hierbei kurz auf REST an sich eingehen, bevor eine Schnittstelle definiert und dann als Mojolicious-Anwendung mit Leben gefüllt wird. Dabei werden dann auch Themen wie Sicherheit etc. angesprochen. Zum Abschluss wird die Schnittstelle noch getestet.

Als Veranstaltungsort ist das Hotel Michaelis geplant und die Teilnehmerzahl ist auf 10 Personen pro Schulung beschränkt.

Wer Interesse an einer der Schulungen hat, kann sich gerne bei uns melden. Die Teilnahme an einer Schulung kostet 200,00 € netto (238,00 € inkl. MwSt), ein Kombiticket für beide Schulungen kostet 350,00 € netto (416,50 € inkl. MwSt).

Wir werden natürlich die Entwicklungen bzgl. Corona weiter im Auge behalten. Sollte eine Präsenzveranstaltung nicht möglich sein, werden wir die Schulungen als Online-Veranstaltung anbieten.


Permalink: