{"meta":{"title":"Création et test de Java avec Gradle","intro":"Découvrez comment créer un flux de travail d’intégration continue (CI) dans GitHub Actions pour générer et tester votre projet Java avec Gradle.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/actions","title":"GitHub Actions"},{"href":"/fr/actions/tutorials","title":"Tutoriels"},{"href":"/fr/actions/tutorials/build-and-test-code","title":"Générer et tester du code"},{"href":"/fr/actions/tutorials/build-and-test-code/java-with-gradle","title":"Java avec Gradle"}],"documentType":"article"},"body":"# Création et test de Java avec Gradle\n\nDécouvrez comment créer un flux de travail d’intégration continue (CI) dans GitHub Actions pour générer et tester votre projet Java avec Gradle.\n\n## Introduction\n\nCe guide vous montre comment créer un flux de travail 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 quand les commits de 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.\n\nLes exécuteurs hébergés dans GitHubont un cache d’outils avec des logiciels préinstallés, incluant des kits de développement Java (JDK) et Gradle. Pour obtenir la liste des logiciels et des versions préinstallées de JDK et de Gradle, consultez « [Exécuteurs hébergés par GitHub](/fr/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software) ».\n\n## Prérequis\n\nVous devez être familiarisé avec YAML et la syntaxe GitHub Actions. Pour plus d’informations, consultez l’article suivant :\n\n* [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions)\n* [Écriture de workflows](/fr/actions/learn-github-actions)\n\nNous vous recommandons d’avoir une compréhension de base des Java et de l’infrastructure Gradle. Pour plus d’informations, consultez le [manuel utilisateur de Gradle](https://docs.gradle.org/current/userguide/userguide.html).\n\n## Utilisation d’un modèle de workflow Gradle\n\nPour démarrer rapidement, ajoutez un modèle de workflow au répertoire `.github/workflows` de votre référentiel.\n\nGitHub fournit un modèle de flux de travail pour Gradle qui doit fonctionner pour la majorité des projets Java utilisant Gradle. Les sections suivantes de ce guide donnent des exemples de la manière dont vous pouvez personnaliser ce modèle de workflow.\n\n1. Sur GitHub, accédez à la page principale du référentiel.\n\n2. Sous le nom de votre référentiel, cliquez sur ** Actions**.\n\n ![Capture d’écran des onglets du référentiel « github/docs ». L’onglet « Actions » est mis en surbrillance avec un encadré orange.](/assets/images/help/repository/actions-tab-global-nav-update.png)\n\n3. Si vous disposez déjà d’un workflow dans votre dépôt, cliquez sur **Nouveau workflow**.\n\n4. La page « Choisir un workflow » présente une sélection de modèles de workflow recommandés. Recherchez « Java avec Gradle ».\n\n5. Dans le flux de travail « Java avec Gradle », cliquez sur **Configure**.\n Ce workflow effectue les étapes suivantes :\n\n6. Extrait une copie du dépôt du projet.\n\n7. Configure le JDK Java.\n\n8. Configure l’environnement Gradle. L’action [`gradle/actions/setup-gradle`](https://github.com/gradle/actions) effectue la mise en cache de l’état entre les exécutions de flux de travail et fournit un résumé détaillé de toutes les exécutions Gradle.\n\n9. L'étape \"Générer avec Gradle\" exécute la tâche `build` à l'aide du [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html).\n\n10. Modifiez le workflow en fonction des besoins. Par exemple, modifiez la version de Java.\n\n > \\[!NOTE]\n >\n > * Ce modèle de workflow contient 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.\n > * 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 « [Informations de référence sur l’utilisation sécurisée](/fr/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions) ».\n\n11. Cliquez sur **Commiter les changements**.\n\nLe fichier de workflow `gradle.yml` est ajouté au répertoire `.github/workflows` de votre dépôt.\n\n### Spécification de la version et de l’architecture de Java\n\nLe modèle de workflow configure le `PATH` pour qu’il contienne 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.\n\nPar 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`.\n\n```yaml copy\nsteps:\n - uses: actions/checkout@v6\n - name: Set up JDK 11 for x64\n uses: actions/setup-java@v4\n with:\n java-version: '11'\n distribution: 'temurin'\n architecture: x64\n```\n\nPour plus d’informations, consultez l’action [`setup-java`](https://github.com/actions/setup-java).\n\n## Génération et test de votre code\n\nVous pouvez utiliser les mêmes commandes que celles que vous utilisez localement pour générer et tester votre code.\n\nLe modèle de workflow exécutera 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.\n\nSi 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 `package` tâche qui est configurée dans votre `ci.gradle` fichier.\n\n```yaml copy\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\nsteps:\n - uses: actions/checkout@v6\n - uses: actions/setup-java@v4\n with:\n java-version: '17'\n distribution: 'temurin'\n\n - name: Setup Gradle\n uses: gradle/actions/setup-gradle@017a9effdb900e5b5b2fddfb590a105619dca3c3 # v4.4.2\n\n - name: Build with Gradle\n run: ./gradlew -b ci.gradle package\n```\n\n## Mise en cache des dépendances\n\nVos 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/actions/setup-gradle` 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.\n\nLa mise en cache est activée par défaut lors de l’utilisation de l’action `gradle/actions/setup-gradle`. Pour plus d’informations, consultez [`gradle/actions/setup-gradle`](https://github.com/gradle/actions/blob/main/setup-gradle/README.md#caching-build-state-between-jobs).\n\n## Empaquetage des données de workflow en tant qu’artefacts\n\nUne fois que votre build a réussi et que vos tests ont réussi, vous pouvez charger les packages de Java résultants en tant qu’artefact 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 les pull requests dans votre environnement local avant la fusion. Pour plus d’informations, consultez « [Stocker et partager des données avec les artefacts de workflow](/fr/actions/using-workflows/storing-workflow-data-as-artifacts) ».\n\nGradle 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`.\n\n```yaml copy\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\nsteps:\n - uses: actions/checkout@v6\n - uses: actions/setup-java@v4\n with:\n java-version: '17'\n distribution: 'temurin'\n\n - name: Setup Gradle\n uses: gradle/actions/setup-gradle@017a9effdb900e5b5b2fddfb590a105619dca3c3 # v4.4.2\n\n - name: Build with Gradle\n run: ./gradlew build\n\n - name: Upload build artifacts\n uses: actions/upload-artifact@v4\n with:\n name: Package\n path: build/libs\n```"}