Java bauen und testen mit Gradle

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

In diesem Artikel

Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.

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 Build-Systems Gradle 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. Sie können Ihren CI-Workflow auf Cache-Dateien erweitern und Artefakte aus einer Workflow-Ausführung hochladen.

GitHub-gehostete Runner haben einen Toolcache mit vorinstallierter Software, zu der Java Development Kits (JDKs) und Gradle gehören. Eine Liste der Software und der vorinstallierten Versionen für JDK und Gradle findest du unter Verwenden von auf GitHub gehosteten Runnern.

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 Gradle haben. Weitere Informationen findest du im Gradle-Benutzerhandbuch.

Verwendung von selbstgehosteten Runnern auf GitHub Enterprise Server

Wenn du Setup-Aktionen (wie z.B.actions/setup-LANGUAGE) auf GitHub Enterprise Server mit selbstgehosteten Runnern verwendest, musst du möglicherweise den Tools-Cache auf Runnern einrichten, die keinen Internetzugang haben. Weitere Informationen finden Sie unter Einrichten des Toolcaches auf selbstgehosteten Runnern ohne Internetzugriff.

Verwenden einer Gradle-Workflowvorlage

Fügen Sie für einen schnellen Einstieg dem Verzeichnis .github/workflows Ihres Repositorys eine Workflowvorlage hinzu.

GitHub bietet eine Workflowvorlage für Gradle, die für die meisten Projekte für Java mit Gradle funktionieren sollte. In den nachfolgenden Abschnitten dieser Anleitung finden Sie Beispiele dafür, wie diese Workflowvorlage angepasst werden kann.

  1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

  2. Klicke unter dem Namen deines Repositorys auf Aktionen.

    Screenshot: Registerkarten für das Repository „github/docs“. Die Registerkarte „Aktionen“ ist mit einem orangefarbenen Rahmen hervorgehoben.

  3. Wenn du bereits über einen Workflow im Repository verfügst, klicke auf Neuer Workflow.

  4. Auf der Seite „Workflow auswählen“ wird eine Auswahl empfohlener Workflowvorlagen angezeigt. Suchen Sie nach „Java mit Gradle“.

  5. Klicken Sie im Workflow „Java mit Gradle“ auf Konfigurieren.

    Wenn Sie die Workflowvorlage „Java mit Gradle“ nicht finden, kopieren Sie den folgenden Workflowcode in eine neue Datei namens gradle.yml im Verzeichnis .github/workflows Ihres Repositorys.

    YAML
    name: Java CI with Gradle

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'

    - name: Setup Gradle
      uses: gradle/actions/setup-gradle@af1da67850ed9a4cedd57bfd976089dd991e2582 # v4.0.0

    - name: Build with Gradle
      run: ./gradlew build

Dieser Workflow führt die folgenden Schritte aus:

  1. Checkt eine Kopie des Projekt-Repositorys aus.

  2. Richtet das Java JDK ein.

  3. Richtet die Gradle-Umgebung ein. Die Aktion gradle/actions/setup-gradle übernimmt das Zwischenspeichern des Zustands zwischen Workflowausführungen und liefert eine detaillierte Zusammenfassung aller Gradle-Ausführungen.

  4. Im Schritt „Erstellen mit Gradle“ wird die Aufgabe build mit dem Gradle Wrapper ausgeführt.

  5. Bearbeiten Sie den Workflow nach Bedarf. Ändern Sie beispielsweise die Java-Version.

    Hinweise:

    • Diese Workflowvorlage enthält eine Aktion, die nicht von GitHub zertifiziert wurde. Aktionen, die von einem Drittanbieter bereitgestellt werden unterliegen separaten Nutzungsbedingungen, Datenschutzrichtlinien und Supportdokumentationen.
    • Wenn du Aktionen von Drittanbietern verwendest, solltest du eine Version verwenden, die durch einen Commit-SHA angegeben ist. Wenn die Aktion überarbeitet wird und du die neuere Version verwenden möchtest, musst du den SHA aktualisieren. Du kannst eine Version auch angeben, indem du auf ein Tag oder einen Branch verweist, aber die Aktion kann sich ohne Vorwarnung ändern. Weitere Informationen findest du unter Sicherheitshärtung für GitHub Actions.

  6. Klicke auf Änderungen committen.

Spezifizieren der Java-Version und -Architektur

Die Workflowvorlage 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@v4
    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.

Die Workflowvorlage führt standardmäßig die build-Aufgabe aus. In der Standard-Gradle-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 einen anderen Task auszuführen möchtest, kannst du dies angeben. Du kannst beispielsweise die package-Aufgabe ausführen, die in der ci.gradle-Datei konfiguriert ist.

YAML
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-java@v4
    with:
      java-version: '17'
      distribution: 'temurin'

  - name: Setup Gradle
    uses: gradle/actions/setup-gradle@af1da67850ed9a4cedd57bfd976089dd991e2582 # v4.0.0

  - name: Build with Gradle
    run: ./gradlew -b ci.gradle package

Abhängigkeiten „cachen“ (zwischenspeichern)

Deine Buildabhängigkeiten können zwischengespeichert werden, um deine Workflowausführungen zu beschleunigen. Nach einer erfolgreichen Ausführung werden wichtige Teile des Basisverzeichnisses für Gradle-Benutzer von gradle/actions/setup-gradle zwischengespeichert. In künftigen Aufträgen wird der Cache wiederhergestellt, sodass Buildskripts nicht neu kompiliert werden müssen und Abhängigkeiten nicht erneut aus Remotepaketrepositorys heruntergeladen werden müssen.

Das Zwischenspeichern ist standardmäßig aktiviert, wenn die Aktion gradle/actions/setup-gradle verwendet wird. Weitere Informationen finden Sie unter gradle/actions/setup-gradle.

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 und Freigeben von Daten aus einem Workflow.

Gradle erstellt normalerweise Ausgabedateien wie JARs, EARs oder WARs im Verzeichnis build/libs. Du kannst den Inhalt dieses Verzeichnisses mit der Aktion upload-artifact hochladen.

YAML
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-java@v4
    with:
      java-version: '17'
      distribution: 'temurin'

  - name: Setup Gradle
    uses: gradle/actions/setup-gradle@af1da67850ed9a4cedd57bfd976089dd991e2582 # v4.0.0

  - name: Build with Gradle
    run: ./gradlew build

  - name: Upload build artifacts
    uses: actions/upload-artifact@v3
    with:
      name: Package
      path: build/libs