actions/setup-java : installer et configurer Java dans GitHub Actions
Configurez votre workflow GitHub Actions avec une version spécifique de Java.
En bref
- De quoi s’agit-il ?
- Action GitHub pour télécharger une distribution Java, configurer l'environnement et mettre en cache les dépendances de build Maven, Gradle ou sbt
- À qui s’adresse-t-il ?
- Adoptez v5 pour vos workflows de production actuellement ; v6 apporte l'ESM et prend en charge 16 distributions différentes, idéal pour les projets nécessitant Scala, Kotlin ou Gradle moderne. Validez d'abord vos commandes maven-gpg-plugin 3.2.0+ si vous signiez vos artefacts.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 5 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Fonction principale et distributions Java
actions/setup-java, écrite en TypeScript, simplifie l'intégration de Java dans vos workflows GitHub Actions. Elle télécharge une distribution Java spécifiée, l'ajoute à la variable PATH, configure JAVA_HOME et crée les fichiers de configuration nécessaires pour les outils de build. Selon le README officiel, elle accepte une version Java demandée, une version lue depuis un fichier comme .java-version ou .sdkmanrc, ou l'alias latest pour la dernière version GA stable.
L'action supporte 16 distributions différentes : Amazon Corretto, Alibaba Dragonwell, Oracle GraalVM, GraalVM Community, JetBrains Runtime, Tencent Kona, Liberica, Liberica Native Image Kit, Microsoft Build of OpenJDK, Oracle JDK, Oracle OpenJDK, SAP SapMachine, IBM Semeru, Eclipse Temurin, Azul Zulu, et un jdkfile personnalisé pour les archives locales. Elle génère des configurations Maven settings.xml personnalisées, configure les toolchains Maven pour gérer plusieurs JDK simultanément, met en cache les archives JDK téléchargées entre les travaux, et enregistre des problem matchers pour signaler les erreurs de compilation et les exceptions non capturées directement dans l'interface GitHub Actions. Elle supporte également la vérification des signatures de paquet pour les distributions supportées et la signature des artefacts avec GPG.
Configuration des versions et paramètres essentiels
Quatre syntaxes de version sont acceptées : les versions majeures (8, 11, 17, 21, 25), les versions de correctif (11.0, 11.0.4), les versions multi-champs JEP 322 (18.0.1.1), et l'alias latest pour la plus récente version GA. Les versions early-access (EA) peuvent être ciblées si disponibles chez le fournisseur.
Le paramètre java-version-file autorise la lecture de la version depuis un fichier de configuration. Les formats supportés incluent .java-version, .tool-versions et .sdkmanrc. Quand un .sdkmanrc contient un suffixe de distribution comme java=21.0.5-tem, l'action détecte automatiquement la distribution correspondante. Les paramètres centraux incluent distribution (temurin, corretto, etc.), check-latest pour vérifier la dernière version en ligne, force-download: true pour contourner le cache du runner, set-default: false pour installer sans modifier JAVA_HOME ou PATH, problem-matcher: false pour désactiver les annotateurs, et verify-signature: true pour valider les signatures des distributions supportées. Les sorties exposent distribution et version détectées, path du JDK installé, cache-hit (true si restauré du cache) et cache-primary-key (clé utilisée pour la restauration).
Mise en cache des dépendances et du JDK
L'action gère trois niveaux de mise en cache. Le cache de dépendances stocke ~/.m2/repository pour Maven, ~/.gradle/caches pour Gradle ou les répertoires de cache sbt. Les caches de wrapper sauvegardent les distributions Maven Wrapper et Gradle Wrapper. Le cache JDK conserve l'installation Java téléchargée entre les travaux.
Définir cache: maven, cache: gradle ou cache: sbt active automatiquement la mise en cache des dépendances et du JDK. Les clés de cache intègrent l'OS du runner, son architecture et le hachage des fichiers pom.xml, gradle.properties et .mvn/extensions.xml, pour invalider le cache lors de changements de dépendances. Les pull requests peuvent utiliser cache-read-only: true pour restaurer sans créer de nouvelles entrées de cache. Sur les runners auto-hébergés, configurez SEGMENT_DOWNLOAD_TIMEOUT_MINS si les segments prennent trop de temps à restaurer. L'action détecte les jdkFile locaux compressés et les cache également automatiquement quand cache est défini.
Vérification de l'intégrité et configuration Maven
L'action valide automatiquement les sommes de contrôle des archives téléchargées lorsque la distribution publie des checksums faisant autorité. Cela couvre actuellement Temurin, Semeru, Corretto, Dragonwell, Kona, SapMachine, GraalVM, GraalVM Community, Zulu, Oracle, Oracle OpenJDK, Microsoft Build of OpenJDK et JetBrains Runtime. La vérification des signatures (verify-signature: true) est disponible pour Temurin et Microsoft Build of OpenJDK. Les installations provenant du cache des outils du runner ne sont pas re-téléchargées ni re-vérifiées, sauf si force-download: true est défini.
Pour les workflows de publication, l'action génère settings.xml avec plusieurs entrées de serveur pour les identifiants de dépôt. Les passphrases GPG ne sont plus stockées dans la section server de settings.xml, mais passées via gpg.passphraseEnvName en settings.xml. Cela impose maven-gpg-plugin 3.2.0 ou plus récent pour fonctionner correctement. Les clés GPG sont importées dans un répertoire GPG temporaire isolé plutôt que dans le keyring par défaut du runner. Les entrées de répertoire personnalisées pour la résolution de dépendances sont aussi supportées. Utilisez server-username-env-var, server-password-env-var et gpg-passphrase-env-var pour éviter que les anciens noms d'entrée ne soient pris pour des secrets.
Historique des versions et cas d'usage
La version v5 reste stable pour les workflows de production. Elle a amené l'upgrade du runtime Node 20 à Node 24, exigeant que les runners auto-hébergés adoptent v2.327.1 ou plus récent. Les versions v1 à v4 sont obsolètes ; le README conseille une migration vers v5.
La version v6, toujours en développement sur la branche main, migre l'implémentation vers ESM pour supporter les derniers packages @actions/*. Elle ajoute Oracle OpenJDK, Red Hat Build of OpenJDK, Liberica Native Image Kit et étend le support de Tencent Kona jusqu'à JDK 25. Pour tester v6, référencez explicitement la branche main (uses: actions/setup-java@main) ; pour la production, restez sur v5. L'exemple de base du README montre : utiliser actions/checkout@v5, puis actions/setup-java@v5 avec distribution: temurin et java-version: '25', avant d'exécuter java --version pour valider. Pour les builds Maven cached, ajouter cache: maven. Pour les monorepos Gradle, utiliser cache: gradle et cache-dependency-path: '**/build.gradle*' pour cacher tous les projets. Avec plusieurs JDK, déclarer plusieurs étapes setup-java avec set-default: false sur les autres que le premier. Pour tester sur plusieurs versions Java (8, 11, 17), utiliser une matrice de jobs et appeler setup-java dans chaque job avec une version différente.
Conclusion éditoriale
Adoptez v5 pour vos workflows de production actuellement ; v6 apporte l'ESM et prend en charge 16 distributions différentes, idéal pour les projets nécessitant Scala, Kotlin ou Gradle moderne. Validez d'abord vos commandes maven-gpg-plugin 3.2.0+ si vous signiez vos artefacts.
Notes de la communauté