GitHub Actions für automatisierte WordPress Kompatibilitätstests

Use case: Test der PHP-Versions­kompatibilität für ein WP Plugin

Unser öffentliches Google Analytics Plugin läuft auf tausenden unterschiedlichen Systemen. Je nach Webseite und Hoster kann es schnell einmal vorkommen, dass noch etwas ältere WordPress und PHP-Versionen in Verwendung sind. WordPress unterstützt zwar dankbarerweise nicht mehr alle alten PHP-Versionen, allerdings kann es durchaus noch Systeme geben, welche auf 5.6 laufen. Wie können wir also sicherstellen, dass unser Plugin auch abwärtskompatibel ist?

• Variante 1: Indem auf einem gerade verfügbaren alten Server die Plugins nur mal eben kurz zu Testzwecken installiert werden.

• Variante 2: Mit automatisierten Tests, wenig Aufwand und auf einem dedizierten Server, fernab von live Seiten oder Kundenprojekten.

Die zweite Variante ist der ersten klar überlegen, muss aber wohl irgendwo einen Haken haben. Den gibt es bis auf einen kleinen Preis für GitHub nicht, falls man denn wirklich viel testet. Dazu kommen wir aber später noch einmal. Zuerst zum Prinzip: dieses ist denkbar einfach.

Setup

Man braucht dafür als erstes eine Infrastruktur, also einen Server, worauf der Code und entsprechend die Tests laufen können. Dafür gibt es einige Anbieter, darunter Circli Ci, Travis und weitere. Allerdings gibt es auch einen neuen Anbieter und der hat es in sich: GitHub Actions. Der Vorteil von GitHub Actions ist, dass die Tests automatisiert werden können und eigens definierte Events wie Pushs, Issues Created, etc. die Tests starten können. Continuous Integration funktioniert damit übrigens auch, was wohl alle einmal tief durchatmen lässt.

Als zweites braucht man eine Matrix-Testing Konfiguration, die vorgibt, auf welchen Systemen was getestet werden soll. Dazu gehören das Betriebssystem, die Software und die Version. Das kann man sich wie eine Tabelle oder eben auch wie eine namensgebende Matrix vorstellen, in der alle Spezifikationen gesammelt werden. In unserem Fall für WordPress interessiert uns die Kompatibilität mit verschiedenen PHP-Versionen. Die aufklappbare YAML Datei hier unten ist ein Beispiel für eine solche Konfiguration.

name: CI

on: [push]

jobs:
  run:    
    runs-on: ${{ matrix.operating-system }}
    strategy:      
      matrix:
        operating-system: [ubuntu-latest]
        php-versions: ['7.2', '7.3']
    name: PHP ${{ matrix.php-versions }} Test on ${{ matrix.operating-system }}
    steps:
    - name: Checkout
      uses: actions/checkout@v1

    - name: Setup PHP
      uses: shivammathur/setup-php@v1
      with:
        php-version: ${{ matrix.php-versions }}
        extension-csv: mbstring, intl #optional, setup extensions
        ini-values-csv: post_max_size=256M, short_open_tag=On #optional, setup php.ini configuration
        coverage: xdebug #optional, setup coverage driver
        pecl: false #optional, setup PECL

    - name: Check PHP Version
      run: php -v

    - name: Composer install
      run: composer install --optimize-autoloader --prefer-dist
    
    - name: Install WP Tests
      run: bash bin/install-wp-tests.sh wordpress_test root root localhost latest
      
    - name: phpunit tests
      run: ./vendor/bin/phpunit

Die Matrix wird hier zuoberst definiert. In diesem Fall wird auf Ubuntu für PHP 7.1, 7.2 und 7.3 getestet.

Diese Konfiguration setzt voraus, dass die Tests mit wp scaffold plugin-tests eingerichtet wurden, einem äusserst hilfreichen Befehl um die Tests für das Plugin zu starten. Dieser Befehl lässt die Tests je zwei Mal laufen, wenn der Code auf GitHub gepusht wird. Das Resultat sieht dann zum Beispiel wie folgt aus:

Preise

55 Sekunden für PHP 7.1, 7.2 und 7.3, nicht schlecht. Hier kommen wir aber wieder zurück zu den erwähnten Kosten. Nicht die Anzahl der Tests wird verrechnet, sondern wie lange die Tests jeweils gedauert haben. Die daraus resultierende «Währung» ist dementsprechend die Testminute. Je nach GitHub Preisplan sind schon unterschiedlich viele Testminuten enthalten. Bei der kostenlosen Version von GitHub sind es beispielsweise 2000 Testminuten pro Monat. Für Teams gibt es die treffend benannte Variante GitHub Teams, welche kostenpflichtig ist und je nach Anforderungen entweder neun Dollar im Monat pro Teammitglied oder einen gegen oben offenen, kundenspezifischen Preis kostet. Bei der neun Dollar Variante sind 10’000 Testminuten pro Monat dabei, bei der teureren Variante sind es 50’000 Testminuten pro Monat.

Fazit

GitHub Actions ist effizient, was sowohl Zeit als auch Geld anbelangt. Und mit der Continuous Integration obendrauf bekommt man ein Paket, welches man so schnell nicht woanders finden wird. Unsere Empfehlung ist deswegen klar, mit GitHub Actions zu arbeiten.