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. Du kannst deinen CI-Workflow so erweitern, dass er Dateien zwischenspeichert und Artefakte aus einer Workflowausführung hochlädt.
GitHub-gehostete Runner verfügen über einen Toolcache mit vorinstallierter Software, die Java Development Kits (JDKs) und Gradle umfasst. Eine Liste der Software und der vorinstallierten Versionen für JDK und Gradle 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 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 des Gradle-Starterworkflows
GitHub bietet einen Gradle-Starterworkflow, der für die meisten Gradle-basierten Java-Projekte funktioniert. Weitere Informationen findest du unter Gradle-Starterworkflow. Die Standardstartworkflows sind ausgezeichnete Ausgangspunkte beim Erstellen von Build- und Testworkflows, und du kannst den Startworkflow den Anforderungen deines Projekts anpassen.
Um schnell loszulegen, kannst du beim Erstellen eines neuen Workflows den vorkonfigurierten Gradle-Starterworkflow 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.
Hinweise:
- Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert wurden. Sie werden von einem Drittanbieter bereitgestellt und unterliegen separaten Nutzungsbedingungen, Datenschutzrichtlinien und Supportdokumentationen.
- GitHub empfiehlt das Anheften von Aktionen an einen Commit-SHA. Um eine neuere Version zu erhalten, musst du den SHA aktualisieren. Du kannst auch auf ein Tag oder einen Branch verweisen, aber die Aktion kann sich ohne Vorwarnung ändern.
# 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 "Validate Gradle wrapper" step validates the checksums of Gradle Wrapper JAR files present in the source tree. - name: Validate Gradle wrapper uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3 # The "Build with Gradle" step does a build using the `gradle/gradle-build-action` action provided by the Gradle organization on GitHub. The action takes care of invoking Gradle, collecting results, and caching state between jobs. For more information see [`gradle/gradle-build-action`](https://github.com/gradle/gradle-build-action). - name: Build with Gradle uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629 with: arguments: build
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: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3
The "Validate Gradle wrapper" step validates the checksums of Gradle Wrapper JAR files present in the source tree.
- name: Build with Gradle
uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629
with:
arguments: build
The "Build with Gradle" step does a build using the gradle/gradle-build-action
action provided by the Gradle organization on GitHub. The action takes care of invoking Gradle, collecting results, and caching state between jobs. For more information see gradle/gradle-build-action
.
# 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 "Validate Gradle wrapper" step validates the checksums of Gradle Wrapper JAR files present in the source tree.
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3
# The "Build with Gradle" step does a build using the `gradle/gradle-build-action` action provided by the Gradle organization on GitHub. The action takes care of invoking Gradle, collecting results, and caching state between jobs. For more information see [`gradle/gradle-build-action`](https://github.com/gradle/gradle-build-action).
- name: Build with Gradle
uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629
with:
arguments: build
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.
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
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 Starterworkflow 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.
steps: - uses: actions/checkout@v4 - uses: actions/setup-java@v3 with: java-version: '17' distribution: 'temurin' - name: Validate Gradle wrapper uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3 - name: Run the Gradle package task uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629 with: arguments: -b ci.gradle package
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v3
with:
java-version: '17'
distribution: 'temurin'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3
- name: Run the Gradle package task
uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629
with:
arguments: -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/gradle-build-action
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/gradle-build-action
verwendet wird. Weitere Informationen findest du unter gradle/gradle-build-action
.
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.
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.
steps: - uses: actions/checkout@v4 - uses: actions/setup-java@v3 with: java-version: '17' distribution: 'temurin' - name: Validate Gradle wrapper uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3 - name: Build with Gradle uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629 with: arguments: build - uses: actions/upload-artifact@v3 with: name: Package path: build/libs
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v3
with:
java-version: '17'
distribution: 'temurin'
- name: Validate Gradle wrapper
uses: gradle/wrapper-validation-action@ccb4328a959376b642e027874838f60f8e596de3
- name: Build with Gradle
uses: gradle/gradle-build-action@749f47bda3e44aa060e82d7b3ef7e40d953bd629
with:
arguments: build
- uses: actions/upload-artifact@v3
with:
name: Package
path: build/libs