Java bauen und testen mit Maven

In diesem Artikel

Du kannst einen Workflow für Continuous Integration (CI) in GitHub Actions erstellen, um dein Java-Projekt mit Maven zu erstellen und zu testen.

Einführung

Dieser Leitfaden zeigt Dir, wie du einen Workflow erstellen kannst, der eine kontinuierliche Integration (CI) für dein Java-Projekt mit Hilfe des Software-Projektmanagement-Tools Maven durchführt. Der Workflow, den du erstellst, zeigt Dir, wenn Commits zu einem Pull-Request zu Build- oder Testfehlern für deinen Standard-Zweig führen. Dieser Ansatz kann dazu beitragen, dass dein Code immer brauchbar ist. Du kannst deinen CI-Workflow so erweitern, dass er Dateien zwischenspeichert und Artefakte aus einer Workflowausführung hochlädt.

Von GitHub gehostete Runner verfügen über einen Toolcache mit vorinstallierter Software, die Java Development Kits (JDKs) und Maven umfasst. Eine Liste der Software und der vorinstallierten Versionen für JDK und Maven findest du unter Using GitHub-hosted runners.

Voraussetzungen

Du solltest mit YAML und der Syntax für GitHub Actions vertraut sein. Weitere Informationen findest du unter:

Du solltest ein grundlegendes Verständnis von Java und dem Framework Maven haben. Weitere Informationen findest du in der Maven-Dokumentation im Maven-Leitfaden zu den ersten Schritten.

Verwenden des Maven-Startworkflows

GitHub bietet einen Maven-Startworkflow, der für die meisten Maven-basierten Java-Projekte funktioniert. Weitere Informationen findest du unter Maven-Startworkflow.

Um schnell loszulegen, kannst du beim Erstellen eines neuen Workflows den vorkonfigurierten Maven-Startworkflow auswählen. Weitere Informationen findest du unter Schnellstart für GitHub Actions.

Du kannst diesen Workflow auch manuell hinzufügen, indem du eine neue Datei im Verzeichnis .github/workflows deines Repositorys erstellst.

YAML
name: Java CI

Der Name des Workflows. GitHub zeigt die Namen deiner Workflows auf der Registerkarte „Aktionen“ deines Repositorys an. Wenn du name weglässt, zeigt GitHub den Workflowdateipfad relativ zum Stammverzeichnis des Repositorys an.

on: [push]
jobs:
  build:
    runs-on: ubuntu-latest

Du kannst diesen Workflow mit einem anderen Betriebssystem ausführen.

Die Vorlage zum Starter-Workflow konfiguriert Aufträge zur Ausführung unter Linux und verwendet mit GitHub gehostete ubuntu-latest-Runner. Du kannst den runs-on-Schlüssel ändern, um deine Aufträge auf einem anderen Betriebssystem auszuführen.

Beispielsweise kannst du die GitHub-gehosteten Windows-Runner verwendenruns-on: windows-latest. Oder du kannst die GitHub-gehosteten macOS-Runner verwendenruns-on: macos-latest.

Du kannst Aufträge auch in Docker-Containern ausführen oder einen selbst gehosteten Läufer bereitstellen, der auf Deiner eigenen Infrastruktur läuft. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

    steps:
      - uses: actions/checkout@v4

In diesem Schritt wird die Aktion actions/checkout verwendet, um eine Kopie deines Repositorys auf den Runner herunterzuladen.

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'

In diesem Schritt wird die Aktion actions/setup-java verwendet, um das Eclipse Temurin 17-JDK (Java) von Eclipse Adoptium zu konfigurieren.

      - name: Build with Maven
        run: mvn --batch-mode --update-snapshots package

The "Build with Maven" step runs the Maven package target in non-interactive mode to ensure that your code builds, tests pass, and a package can be created.

# Der Name des Workflows. GitHub zeigt die Namen deiner Workflows auf der Registerkarte „Aktionen“ deines Repositorys an. Wenn du `name` weglässt, zeigt GitHub den Workflowdateipfad relativ zum Stammverzeichnis des Repositorys an.
name: Java CI

#
on: [push]
#
jobs:
  build:

    # <!-- This is a YAML comment for use in annotated code examples. -->
    # Du kannst diesen Workflow mit einem anderen Betriebssystem ausführen.
    #
    # Die Vorlage zum Starter-Workflow konfiguriert Aufträge zur Ausführung unter Linux und verwendet mit GitHub gehostete `ubuntu-latest`-Runner. Du kannst den `runs-on`-Schlüssel ändern, um deine Aufträge auf einem anderen Betriebssystem auszuführen.
    #
    # Beispielsweise kannst du die GitHub-gehosteten Windows-Runner verwenden`runs-on: windows-latest`. Oder du kannst die GitHub-gehosteten macOS-Runner verwenden`runs-on: macos-latest`.
    #
    # Du kannst Aufträge auch in Docker-Containern ausführen oder einen selbst gehosteten Läufer bereitstellen, der auf Deiner eigenen Infrastruktur läuft. Weitere Informationen findest du unter [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on).
    runs-on: ubuntu-latest
#
    steps:
      # In diesem Schritt wird die Aktion `actions/checkout` verwendet, um eine Kopie deines Repositorys auf den Runner herunterzuladen.
      - uses: actions/checkout@v4
      # In diesem Schritt wird die Aktion `actions/setup-java` verwendet, um das Eclipse Temurin 17-JDK (Java) von Eclipse Adoptium zu konfigurieren.
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'
      # The "Build with Maven" step runs the Maven `package` target in non-interactive mode to ensure that your code builds, tests pass, and a package can be created.
      - name: Build with Maven
        run: mvn --batch-mode --update-snapshots package

Die Standardstartworkflows sind ausgezeichnete Ausgangspunkte beim Erstellen von Build- und Testworkflows, und du kannst den Startworkflow den Anforderungen deines Projekts anpassen.

Spezifizieren der JVM-Version und -Architektur

Der Starterworkflow richtet PATH so ein, dass OpenJDK 8 für die x64-Plattform enthalten ist. Wenn du eine andere Java-Version verwenden willst oder auf eine andere Architektur (x64 oder x86) abzielen möchtest, kannst du die setup-java-Aktion verwenden, um eine andere Java-Laufzeitumgebung auszuwählen.

Um etwa Version 11 des JDK zu verwenden, das von Adoptium für die x64-Plattform bereitgestellt wird, kannst du die Aktion setup-java verwenden und die Parameter java-version, distribution und architecture für '11', 'temurin' und x64 konfigurieren.

YAML
steps:
  - uses: actions/checkout@v4
  - name: Set up JDK 11 for x64
    uses: actions/setup-java@v3
    with:
      java-version: '11'
      distribution: 'temurin'
      architecture: x64

Weitere Informationen findest du unter der Aktion setup-java.

Deinen Code bauen und testen

Du kannst die gleichen Befehle verwenden, die Du auch lokal verwendest, um Deinen Code zu bauen und zu testen.

Der Startworkflow führt standardmäßig das package-Ziel aus. In der Standard-Maven-Konfiguration lädt dieser Befehl Abhängigkeiten herunter, baut Klassen, führt Tests durch und paketiert Klassen in ihr verteilbares Format, zum Beispiel eine JAR-Datei.

Wenn du zum Bauen deines Projekts andere Befehle verwenden oder ein anderes Ziel auszuführen möchtest, kannst du dies angeben. Du kannst beispielsweise das verify-Ziel ausführen, das in einer Datei pom-ci.xml konfiguriert ist.

YAML
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-java@v3
    with:
      java-version: '17'
      distribution: 'temurin'
  - name: Run the Maven verify phase
    run: mvn --batch-mode --update-snapshots verify

Abhängigkeiten „cachen“ (zwischenspeichern)

Du kannst deine Abhängigkeiten zwischenspeichern, um die Workflow-Ausführungen zu beschleunigen. Nach einer erfolgreichen Ausführung wird dein lokales Maven-Repository in einem Cache gespeichert. Bei zukünftigen Workflow-Ausführungen wird der Cache wiederhergestellt, so dass Abhängigkeiten nicht aus entfernten Maven-Repositories heruntergeladen werden müssen. Du kannst Abhängigkeiten einfach mithilfe der setup-java-Aktion zwischenspeichern oder die cache-Aktion für eine benutzerdefinierte und erweiterte Konfiguration verwenden.

YAML
steps:
  - uses: actions/checkout@v4
  - name: Set up JDK 11
    uses: actions/setup-java@v3
    with:
      java-version: '17'
      distribution: 'temurin'
      cache: maven
  - name: Build with Maven
    run: mvn --batch-mode --update-snapshots verify

Dieser Workflow speichert den Inhalt deines lokalen Maven-Repositorys, das sich im Verzeichnis .m2 des Basisverzeichnisses auf dem Runner befindet. Der Cacheschlüssel ist der Hashinhalt von pom.xml, sodass Änderungen an pom.xml den Cache ungültig machen.

Workflow-Daten als Artefakte paketieren

Nachdem sowohl Build erfolgreich war und deine Tests bestanden hat, wirst du die resultierenden Java-Pakete als Build-Artefakt hochladen wollen. Dies speichert die gebauten Pakete als Teil der Workflow-Ausführung und ermöglicht Dir, sie herunterzuladen. Artefakte können Dir helfen, Pull-Requests in deiner lokalen Umgebung zu testen und zu debuggen, bevor sie zusammengeführt werden („merge“). Weitere Informationen findest du unter Speichern von Workflowdaten als Artefakte.

Maven erstellt normalerweise Ausgabedateien wie JARs, EARs oder WARs im Verzeichnis target. Um diese als Artefakte hochzuladen, kannst du sie in ein neues Verzeichnis kopieren, welches Artefakte zum Hochladen enthält. Zum Beispiel kannst du ein Verzeichnis namens staging erstellen. Anschließend kannst du den Inhalt dieses Verzeichnisses mithilfe der Aktion upload-artifact hochladen.

YAML
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-java@v3
    with:
      java-version: '17'
      distribution: 'temurin'
  - run: mvn --batch-mode --update-snapshots verify
  - run: mkdir staging && cp target/*.jar staging
  - uses: actions/upload-artifact@v3
    with:
      name: Package
      path: staging