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:
- Sources aus Git auschecken.
- Das benötigte JDK verfügbar machen.
- Maven, Gradle, etc. starten.
Java einrichten
Die wichtigste Action zum Start ist setup-java. Hiermit lässt sich die gewünsche Java-Version problemlos bereitstellen. Auch Matrix-Builds für unterschiedliche Java-Versionen werden unterstützt.
Build starten
Sobald Java eingerichtet worden ist, können die gewünschten Tools direkt mit den dazugehörigen Befehlen gestartet werden, indem z. B. mvn
oder gradle
verwendet wird.
Abweichende Versionen nutzen
Per Standard werden immer die Werkzeuge verwendet, die auf dem verwendeten Runner installiert sind. Die Versionen können jederzeit in der Doku nachgeschlagen werden.
Meine Workflows laufen in der Regel auf dem neuen Ubuntu (runs-on: ubuntu-latest
). Dort kommen gegenwärtig Gradle 6.3 und Maven in der Version 3.6.3 zum Einsatz.
In manchen Fällen kann es jedoch vorkommen, dass man explizit eine bestimmte Version nutzen möchte. Dann kann man sich damit behelfen, diese Version einfach händisch in einem vorgelagerten Workflow-Schritt bereitzustellen:
|
|
Das Tool wird dann natürlich nicht mit mvn
, sondern durch maven/bin/mvn
angesprochen.
Ausführlicheres Lesematerial
Mittlerweile gibt es in der Dokumentation für GitHub Actions einen eigenen Bereich, in dem gezeigt wird, wie sich Workflows für Java-Projekte aufbauen lassen. Es lohnt sich, zum Einstieg einen Blick darauf zu werfen.
Ausblick
Im nächsten Artikel gehen wir weg von den allgemeinen Punkten und kommen dafür mehr auf spezifische Aspekte zu sprechen, mit denen man unweigerlich konfrontiert werden wird, sobald man komplexere Build-Systeme mit GitHub Actions realisiert und beispielsweise mehrere Projekte miteinander verketten möchte.