Introduction
Ce guide explique comment créer un workflow qui effectue une intégration continue (CI) pour votre projet Java à l’aide du système de génération Gradle. Le workflow que vous créez vous permet de voir à quel moment les commits de demande de tirage (pull request) entraînent des échecs de build ou de test dans votre branche par défaut. Cette approche peut vous aider à garantir l’intégrité de votre code. Vous pouvez étendre votre workflow CI pour mettre en cache des fichiers et charger des artefacts à partir d’une exécution de workflow.
Les exécuteurs hébergés dans GitHub ont un cache d’outils où des logiciels sont préinstallés, notamment les Java Development Kits (JDKs) et Gradle. Pour obtenir la liste des logiciels et des versions préinstallées de JDK et de Gradle, consultez « Utilisation des exécuteurs hébergés par GitHub ».
Prérequis
Vous devez être familiarisé avec YAML et la syntaxe GitHub Actions. Pour plus d'informations, consultez les pages suivantes :
Il est recommandé d’avoir une compréhension de base de Java et du framework Gradle. Pour plus d’informations, consultez le manuel utilisateur de Gradle.
Utilisation d’un workflow de démarrage pour Gradle
Pour commencer rapidement, ajoutez le workflow de démarrage à l’annuaire .github/workflows
de votre référentiel.
GitHub fournit un workflow de démarrage pour Gradle qui devrait fonctionner pour la plupart des projets Java avec Gradle. Les sections suivantes de ce guide donnent des exemples de la façon dont vous pouvez personnaliser ce workflow de démarrage.
-
Dans GitHub.com, accédez à la page principale du dépôt.
-
Sous le nom de votre dépôt, cliquez sur Actions.
-
Si vous disposez déjà d’un workflow dans votre dépôt, cliquez sur Nouveau workflow.
-
La page « Choisir un workflow » présente une sélection de workflows de démarrage recommandés. Recherchez « Java avec Gradle ».
-
Dans le workflow « Java avec Gradle », cliquez sur Configurer.
-
Modifiez le workflow en fonction des besoins. Par exemple, changez la version de Java.
Remarques :
- Ce workflow utilise une action qui n’est pas certifiée par GitHub. Elles sont fournies par un tiers et sont régies par des conditions d’utilisation du service, une politique de confidentialité et une documentation de support distinctes.
- Si vous utilisez des actions de tiers, vous devez utiliser une version spécifiée par un commit SHA. Si l’action est révisée et que vous voulez utiliser la version la plus récente, vous devez mettre à jour le SHA. Vous pouvez spécifier une version en faisant référence à une balise ou à une branche, mais l’action peut changer sans avertissement. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions ».
-
Cliquez sur Valider les changements.
Le fichier de workflow gradle.yml
est ajouté à l’annuaire .github/workflows
de votre référentiel.
Spécification de la version et de l’architecture de Java
Le workflow de démarrage configure le PATH
pour contenir OpenJDK 8 pour la plateforme x64. Si vous souhaitez utiliser une autre version de Java ou cibler une architecture différente (x64
ou x86
), vous pouvez utiliser l’action setup-java
pour choisir un autre environnement d’exécution Java.
Par exemple, pour utiliser la version 11 du JDK fourni par Adoptium pour la plateforme x64, vous pouvez utiliser l’action setup-java
et configurer les paramètres java-version
, distribution
et architecture
sur '11'
, 'temurin'
et 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
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
Pour plus d’informations, consultez l’action setup-java
.
Génération et test de votre code
Vous pouvez utiliser les mêmes commandes que celles que vous utilisez localement pour générer et tester votre code.
Le workflow de démarrage exécute la tâche build
par défaut. Dans la configuration Gradle par défaut, cette commande télécharge les dépendances, génère les classes, exécute les tests et empaquettent les classes dans un format distribuable, par exemple, dans un fichier JAR.
Si vous utilisez différentes commandes pour générer votre projet ou si vous souhaitez utiliser une autre tâche, vous pouvez les spécifier. Par exemple, vous pouvez exécuter la tâche package
qui est configurée dans votre fichier ci.gradle.
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
Mise en cache des dépendances
Vos dépendances de build peuvent être mises en cache pour accélérer vos exécutions de workflow. Après une exécution réussie, gradle/gradle-build-action
met en cache d’importantes parties du répertoire de base de l’utilisateur Gradle. Dans les prochains travaux, le cache sera restauré pour que les scripts de build n’aient pas à être recompilés et que les dépendances ne doivent pas être téléchargées à partir de dépôts de package distants.
La mise en cache est activée par défaut lors de l’utilisation de l’action gradle/gradle-build-action
. Pour plus d’informations, consultez gradle/gradle-build-action
.
Empaquetage des données de workflow en tant qu’artefacts
Une fois que votre build a été générée et que vos tests ont réussi, vous pouvez charger les packages Java résultants en tant qu’artefacts de build. Cela stockera les packages générés dans le cadre de l’exécution du workflow et vous permettra de les télécharger. Les artefacts peuvent vous aider à tester et à déboguer des demandes de tirage dans votre environnement local avant qu’elles ne soient fusionnées. Pour plus d’informations, consultez « Stockage des données de workflow en tant qu’artefacts ».
Gradle crée généralement des fichiers de sortie comme les fichiers JAR, EAR ou WAR dans le répertoire build/libs
. Vous pouvez charger le contenu de ce répertoire à l’aide de l’action upload-artifact
.
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