19 Commits

Author	SHA1	Message	Date
Julien Dubois	d0e61fe743	Fix JDK resolution cache platform identity (#1210) ... * Fix JDK resolution cache platform identity Include the effective Linux libc platform in JDK resolution cache keys so Alpine/musl and glibc runners cannot restore each other's release metadata. Bump the cache namespace and share Alpine detection with affected distributors.\n\nCo-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>\nCopilot-Session: 4f95577c-567c-47a8-92f2-b4dced527866 * Update generated action bundles Regenerate setup and cleanup distributions for the platform-aware JDK resolution cache.\n\nCo-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>\nCopilot-Session: 4f95577c-567c-47a8-92f2-b4dced527866 * Cover the platform-identity fallback and Alpine short-circuit getJavaPlatformIdentity's `?? platform` fallback and the alias path for platforms other than linux/darwin/win32 had no coverage, and isAlpineLinux had no direct test at all. Verified by mutation: replacing the fallback with a constant, and dropping the `platform === 'linux'` short-circuit from isAlpineLinux, both left the existing suite fully green. The added cases fail on each. The short-circuit case matters beyond coverage bookkeeping: it is what keeps the /etc/alpine-release probe from running on non-Linux runners, so a stray file can never make Windows or macOS resolve as musl. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db * Carry the platform identity into the floating resolution request Merging main brought in #1219, which added getFloatingResolutionRequest as a second construction site for JdkResolutionRequest. It predates the required `platform` field, so the merged tree did not compile. The floating request already carries `source`, which pins the artifact bytes, so this changes no lookup behaviour on its own -- it keeps the two request builders consistent and the tree building. Also refreshes dist/, which the textual merge left stale. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db --------- Co-authored-by: Bruno Borges <brborges@microsoft.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 74248bb0-72af-41d8-b85d-b0f5836e68db	2026-08-05 12:45:11 -04:00
Bruno Borges	2b61aea53d	Reuse the tool cache for floating versions the resolution cache identified (#1219) ... A floating Oracle JDK or Oracle GraalVM request now skips the tool-cache short-circuit entirely, so every job re-downloads and re-extracts the JDK even when the exact bytes the mutable URL currently serves are already installed locally. The JDK resolution cache is keyed on the artifact's checksum (or, failing that, its HTTP response fingerprint), so a hit proves which concrete version the URL is serving right now. Once it has vouched for that version, an existing tool-cache installation of exactly that version is the artifact the download would have produced, and can be reused. Reuse is therefore gated on the resolution cache hit, never on the requested major: an unidentified floating artifact still downloads, as does an explicit force-download. Co-authored-by: Bruno Borges <brunoborges@users.noreply.github.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f2d9a891-a680-4b35-9644-cf2450f76f6d	2026-08-05 12:08:32 -04:00
Julien Dubois	f4bfb3ddea	Report concrete versions for floating Oracle JDK downloads (#1213) ... * Fix floating Oracle JDK version resolution Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Update generated distribution bundles Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Harden floating artifact cache identity Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Regenerate setup bundle after cache hardening Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Temporarily enable hosted full validation Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Export hosted formatting results Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Apply repository formatting Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Run hosted validation after formatting Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Correct floating version regression tests Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Remove temporary validation wiring Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Cache checksum-less floating artifacts by their response fingerprint Oracle and Oracle GraalVM do not always publish a `.sha256` sibling next to a `/latest/` artifact. Those floating releases were excluded from both the resolution cache and the JDK cache, so `cache-jdk` users lost caching entirely for them. A floating URL is a constant string, so it cannot serve as a cache identity on its own — a stale entry would be reused forever. Instead, derive a validator from the headers of the HEAD request that already resolves the artifact: the ETag when present, otherwise `Last-Modified` combined with `Content-Length`. Republishing changes the validator, which changes the cache key, so a new build is downloaded rather than masked. `getJdkReleaseIdentity` now falls back to that fingerprint before the URL, and the floating cache gates ask whether the release has a stable identity (checksum or fingerprint) rather than a checksum specifically. A floating release with neither is still left uncached. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Bruno Borges <brborges@microsoft.com>	2026-08-05 11:57:27 -04:00
Bruno Borges	ab597f914a	Cache resolved JDK releases to remove the vendor API from warm jobs (#1208) ... * Cache resolved JDK releases to remove the vendor API from warm jobs Only Temurin is preinstalled in the runner tool cache, so for every other distribution `findInToolcache()` misses on essentially every job. That forces a call to the distribution's metadata API before the JDK cache key can even be computed, which makes the vendor a hard per-job dependency even when the JDK bytes are already cached, and turns a vendor 403, 429, or outage into a job failure. Store the resolved release in a small companion cache entry keyed only on inputs known before any network call: runner OS, architecture, distribution, package type, requested version, and stability. A job that finds a current entry installs the JDK without contacting the metadata API at all. `@actions/cache` derives a cache version by hashing the requested paths, so save and restore paths must match. The entry therefore uses a path that excludes the date bucket while the key includes it, which lets restore keys fall back to an older bucket. An entry older than the current day is not used directly: the metadata API is still queried so floating requests such as `java-version: 21` keep picking up new releases, and the older entry is used only when that query fails. Because the entry also carries the download URL and checksum, that fallback works even when the JDK itself is not cached. Releases whose URL is not content-addressed are never stored. Oracle JDK and Oracle GraalVM build a `/latest/` URL for a major-only version, and its bytes change when a new build is published, so the URL and checksum are only consistent at the moment they are resolved. Mark those releases floating and skip recording them. Restored payloads are validated as untrusted input, and the post-job save rewrites the payload the key was computed for rather than uploading whatever is on disk, since a restore in a later step targets the same path. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644 * Widen the resolution freshness window from a day to a week A daily window gives no benefit to the repositories that need it most. A repository whose workflows run once a day would re-resolve on every job, and one running weekly would never see a current entry at all, yet those are exactly the repositories with nothing warm in the tool cache. Seven days is also the ceiling. GitHub removes cache entries that have not been accessed for seven days, so a longer window would leave the previous entry evicted by the time the window rolls over, removing the stale fallback at the moment it is most likely to be needed. It comfortably covers JDK release cadence, which is monthly at its fastest and usually quarterly. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Rebuild dist to match the linted source The pre-commit hook runs `eslint --fix` after `npm run check` has already built `dist/`, so the fix it applied to the resolution fallback warning in `base-installer.ts` never reached the bundle. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644 * Rebuild dist to match the linted source The autofix accepted on the pull request edited the resolution fallback warning in `base-installer.ts` through the GitHub UI, which does not run `npm run build`, so `dist/` still carried the pre-fix bundle. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644 --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Copilot-Session: b76d8cb0-f629-46e1-bf9a-ffde06948644	2026-08-04 23:58:03 -04:00
Bruno Borges	955f34f16f	Add conditional JDK caching (#1201) ... * Add JDK caching Cache resolved JDK tool-cache entries by exact platform and release identity, with a default-on cache-jdk input and explicit opt-out. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Apply batched suggestions from code review Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Fix JDK cache CI validation Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Update brace-expansion security fix Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Refresh brace-expansion license metadata Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Refine JDK cache semantics Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Refine JDK cache documentation Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Simplify JDK cache identity Use one normalized runner OS dimension, reset the internal cache key schema for the unreleased feature, and align documentation, tests, and bundles. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Align JDK cache OS identity Use the established RUNNER_OS value directly and retain process.platform only as a non-Actions fallback. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Harden JDK cache saves and document tool-cache reuse Bind each JDK cache key to the installation identity it was computed for, keep post-job saves best-effort per entry, and state the real reuse and verification guarantee in the documentation. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * docs: restructure README caching section Rename '## Caching dependencies' to '## Caching' and add a what-gets-cached overview table covering the dependency, wrapper, and JDK caches. Lead with the common 'cache: maven' example and the dependency-cache material, and demote JDK caching into its own subsection. Also corrects the IMPORTANT callout, which implied JDK caching required an explicit opt-in; it is enabled implicitly whenever 'cache' is set. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * docs: fix caching documentation defects - Remove pull-request framing that compared behavior to `main`; state the tool-cache and `jdkfile` behavior directly and unconditionally. - Clarify that the JDK cache is a separate cache *entry* from the dependency and wrapper caches, while its *enablement* is coupled to `cache`, so the opening paragraph agrees with the enablement matrix. - Cite the actions/setup-java-benchmarks repository instead of an open PR and a self-referential PR comment, keeping the measured figures and caveats. - Keep the `cache`/`cache-jdk` matrix only in docs/advanced-usage.md and summarize the rules in prose in README.md to avoid divergence. - Describe the guarantee that a cache key is only saved with the installation it was computed for, instead of documenting inode/size/timestamp internals. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * docs: add V6 what's new entry for JDK caching Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: e2755464-4e83-47b6-ba71-731bb481b418 --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Copilot-Session: e2755464-4e83-47b6-ba71-731bb481b418	2026-08-04 21:54:10 -04:00
Bruno Borges	27f2c62824	Verify JDK downloads with vendor checksums (#1167) ... * Verify JDK downloads with vendor checksums Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a800a031-600e-4d28-b23e-be309555d38d * Handle missing vendor checksum values Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a800a031-600e-4d28-b23e-be309555d38d * Preserve checksum error during cleanup failure Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a800a031-600e-4d28-b23e-be309555d38d * Validate checksum metadata value types Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a800a031-600e-4d28-b23e-be309555d38d * Clarify checksum documentation Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a800a031-600e-4d28-b23e-be309555d38d * Expand vendor checksum verification Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a800a031-600e-4d28-b23e-be309555d38d * Accept SHA-256 or SHA-512 for JetBrains checksum sibling JetBrains publishes a single, generically-named ".checksum" sibling whose digest algorithm isn't disclosed by the filename. Older JBR 11 builds (e.g. jbrsdk_nomod-11_0_16-*-b2043.64.tar.gz) publish a SHA-256 digest there, while newer builds publish SHA-512. The JetBrains installer previously assumed SHA-512 unconditionally, so verification failed with "Malformed sha512 checksum metadata ... expected a 128-character hexadecimal digest" for those older builds, breaking the jetbrains 11 e2e job on macOS and Windows. fetchChecksum now accepts a list of candidate algorithms and infers the actual algorithm from the returned digest's length, preferring the strongest match. The JetBrains installer passes ['sha512', 'sha256']; all other callers are unaffected since they already pass a single, vendor-disclosed algorithm. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a800a031-600e-4d28-b23e-be309555d38d * Use SapMachine archive checksum files Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a800a031-600e-4d28-b23e-be309555d38d --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a800a031-600e-4d28-b23e-be309555d38d	2026-07-29 04:43:56 -04:00
Bruno Borges	5894ef6b27	Consolidate JDK metadata retry handling (#1162) ... * Consolidate JDK metadata retries Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a5e2549a-0d89-4c8f-b7f3-411ad21c8a06 * Expand distribution retry coverage Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a5e2549a-0d89-4c8f-b7f3-411ad21c8a06 --------- Copilot-Session: a5e2549a-0d89-4c8f-b7f3-411ad21c8a06	2026-07-29 00:09:37 -04:00
Copilot	089b010dc8	Add force-download option for reproducible JDK builds (#1148) ... * Initial plan * Add force-download input * Build force-download action bundles --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Bruno Borges <brborges@microsoft.com>	2026-07-28 14:43:47 -04:00
Bruno Borges	174d4b5609	Support pinning java-version as "latest" (#1093) ... * Support pinning java-version as "latest" Add a `latest` alias for the `java-version` input that floats to the newest available stable (GA) release. It is normalized to the SemVer wildcard at the base-installer layer and always resolves from remote (like `check-latest: true`). List-based distributions resolve it automatically via the existing newest-first matching. Corretto selects its newest available major; Oracle and GraalVM look up the newest GA major via the Adoptium API and request it, failing with an actionable error if that major isn't published yet. The jdkfile distribution rejects `latest`. Closes #832 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Clarify latest note for oracle/graalvm version resolution vs download Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * graalvm-community: float latest to its own newest GA release GraalVM Community publishes its releases on GitHub, so the `latest` alias now matches against that real release list using the SemVer wildcard instead of asking the Adoptium API for the newest GA major. This prevents `latest` from hard-failing when GraalVM lags behind a freshly released Java major (e.g. Adoptium reports 26 before GraalVM ships it). Oracle GraalVM has no listing endpoint, so it keeps deriving the newest major from Adoptium and errors clearly if that major is not yet published. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Give latest+qualifier inputs (e.g. latest-ea) a targeted error Inputs like 'latest-ea' had their '-ea' suffix stripped and fell through to the generic SemVer validation, failing with a confusing "'latest' is not valid SemVer" message even though 'latest' is supported. Add an explicit guard so any 'latest*' value other than exactly 'latest' throws a targeted error explaining that 'latest' resolves GA releases only and cannot be combined with '-ea' or other qualifiers. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>	2026-07-09 20:11:03 -04:00
Bruno Borges	3157986b3f	Support multi-field Java versions like 18.0.1.1 (#1092) ... Java's version scheme (JEP 322) can contain more than the three numeric fields SemVer allows, e.g. 18.0.1.1 or 11.0.9.1. normalizeVersion() rejected these inputs. Convert exact multi-field versions to SemVer build notation (18.0.1.1 -> 18.0.1+1) before validation, reusing the existing convertVersionToSemver() helper. Ranges, EA tags, and inputs that already carry build metadata are left untouched. Fixes: #326 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>	2026-07-09 15:24:02 -04:00
Priya Gupta	f7121373a9	Migrate to ESM and upgrade dependencies (#1078) ... * Migrate to ESM and upgrade dependencies * fix: update import statement for JSON module in kona-installer test --------- Co-authored-by: George Adams <georgeadams1995@gmail.com>	2026-07-08 10:15:00 +01:00
Guillaume Smet	6657b99340	feat: Add set-default option (#1017) ... * Add set-default option This option allows to install an additional JDK without making it the default one. I have wanted this for quite a long time as I'm running custom GitHub Actions with Java, which might require a specific JDK and I don't want to pollute the JDK that is used by the overall workflow calling the action. And I'm apparently not alone as there was a preexisting issue. Fixes #560 * Dedupe setJavaDefault and document multi-version/toolchain behavior - Refactor setJavaDefault to delegate shared output/env logic to setJavaEnvironment, avoiding duplication between the two. - Document that set-default applies to all JDKs in a multiline java-version, and that installed JDKs remain registered in Maven toolchains regardless of set-default. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: fix Prettier formatting in base-installer test Resolves the failing 'Basic validation / build' format-check on __tests__/distributors/base-installer.test.ts (line exceeded print width). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Bruno Borges <brborges@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>	2026-07-07 12:38:57 -04:00
John	b150355f04	feat: Add verify-signature plumbing and Temurin+Microsoft verification support (#1060) ... * Add verify-signature plumbing and Temurin verification support * Rebuild dist after signature verification changes * Refine signature verification errors and regenerate dist * refactor: make gpg.ts generic, move Adoptium-specific constant to temurin distribution * fix: mock renameWinArchive in temurin tests and add signature e2e job * refactor: bundle Adoptium public key, replace keyserver lookup with local import * feat: add verify-signature-public-key input to allow custom GPG key override * refactor: extract Adoptium public key to adoptium-key.ts; tighten gpg.ts cleanup scope * Add verify-signature plumbing and Temurin verification support * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Add Microsoft signature verification support * Regenerate dist bundles for Microsoft signature checks * Harden Microsoft signature URL handling * Add setup-java-microsoft-signature-verification e2e job * chore: regenerate dist files * Fix e2e-versions: remove duplicate job, update signature jobs to checkout@v7 with env vars * Fix Prettier formatting in test files * fix: mock renameWinArchive in microsoft-installer tests to fix Windows CI failure * fix: use --homedir flag instead of GNUPGHOME env var for Windows GPG compatibility The Git-bundled GPG on Windows (MSYS2-based) does not automatically convert Windows-style paths in environment variables like GNUPGHOME. This caused GPG to fail with exit code 2 when verifying Microsoft JDK signatures on Windows, because the GNUPGHOME path (D:\a\_temp\...) was not recognized as a valid POSIX path. Fix: pass --homedir as an explicit command-line argument to both gpg --import and gpg --verify. MSYS2 does correctly convert Windows paths in command-line arguments, so this approach works reliably on Windows, Linux, and macOS. * fix: convert Windows paths to POSIX format for MSYS2 GPG on Windows The Git-bundled GPG on Windows (C:\Program Files\Git\usr\bin\gpg.exe) is an MSYS2-based binary that uses POSIX path conventions internally. When Windows-style paths with backslashes and drive letters (D:\a\_temp\...) are passed as arguments, GPG may fail to resolve them correctly, resulting in a fatal error (exit code 2). Fix: add a toGpgPath() helper that converts Windows paths to MSYS2 POSIX format (/d/a/_temp/...) before passing them to any gpg command. On Linux and macOS the helper is a no-op. Applied to all four paths used in verifyPackageSignature: - gpgHome (--homedir argument) - publicKeyFile (--import argument) - signaturePath (--verify signature argument) - archivePath (--verify data argument) * Fix gpg test formatting --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Bruno Borges <brborges@microsoft.com>	2026-06-29 13:19:49 +01:00
Chiranjib Swain	0756542bc5	Refactor error handling and improve test logging for installers (#989) ... * Refactor error handling for version not found cases across multiple installers * Mock core.error in tests to suppress error logs * fix(graalvm): improve error messages for EA version not found scenarios * refactor(tests): update error messages for version not found scenarios * fix(graalvm): enhance error messages for version not found scenarios * fix(graalvm): improve error messages for version not found scenarios with updated download URL * fix(graalvm): improve error handling for EA version not found scenarios with clearer messages	2026-04-13 12:44:45 -05:00
Salman Chishti	0913e9a06e	Upgrade to node 24 (#888) ... * Upgrade to node 24 Upgrading action to node 24 since new runner version. * fix tests * Fix tests and licences * format * format x2 * Upgrade Node.js version in workflow files to 24.x * check failure fix * check failures fix * Fix mock platform --------- Co-authored-by: Aparna Jyothi <aparnajyothi-y@github.com> Co-authored-by: Haritha <73516759+HarithaVattikuti@users.noreply.github.com>	2025-08-20 14:07:47 -05:00
Ivan	0de5c66fc0	Add and configure ESLint and update configuration for Prettier (#458) ... * Add ESLint config and update Prettier * Update test files * Rebuild action * Update docs * Update licenses * Update tsconfig * Rebuild action * Update tsconfig.json * Fix console.time calls * Rebuild action * Rebuild action on Linux	2023-03-09 14:49:35 +02:00
Wes Morgan	3617c43588	Default to runner architecture (#376)	2022-10-11 01:47:17 +02:00
Dmitry Shibanov	d854b6da19	Add support for multiple jdks (#368)	2022-09-08 15:26:54 +02:00
Maxim Lobanov	b53500dabc	Merge "v2-preview" branch into "main" (#150) ... * actions/setup-java@v2 - Support different distributions (#132) * Implement support for custom vendors in setup-java * minor improvements * minor refactoring * Add unit tests and e2e tests * Update documentation for setup-java@v2 release * minor improvements * regenerate dist * fix comments * resolve comments * resolve comments * fix tests * Update README.md Co-authored-by: George Adams <george.adams@microsoft.com> * Apply suggestions from code review Co-authored-by: Konrad Pabjan <konradpabjan@github.com> * fix minor nitpicks * handle 4th digit * pull latest main * Update README.md * rename adoptium to adopt * rename adoptium to adopt * rename adoptium to adopt * Update README.md * make java-version and distribution required for action * update readme * fix tests * fix e2e tests Co-authored-by: George Adams <george.adams@microsoft.com> Co-authored-by: Konrad Pabjan <konradpabjan@github.com> * Add "overwrite-settings" input parameter (#136) * add overwrite-settings parameter * fix e2e tests * print debug * fix e2e tests * add comment * remove comment * Add "Contents/Home" postfix on macOS if provider creates it (#139) * Update e2e-versions.yml * Update e2e-versions.yml * implement fix * Update e2e-versions.yml * Update installer.ts * fix filter logic * Update e2e-versions.yml * remove extra logic * Update e2e-versions.yml * Add check-latest flag (#141) * add changes for check-latest * run prerelease script * resolving comments * fixing tests * fix spelling * improve core.info messages * run format * run prerelease * change version to fix test * resolve comment for check-latest * Update README.md * added hosted tool cache section * Apply suggestions from code review Co-authored-by: Maxim Lobanov <v-malob@microsoft.com> Co-authored-by: Konrad Pabjan <konradpabjan@github.com> * Avoid "+" sign in Java path in v2-preview (#145) * try to handle _ versions * more logs * more debug * test 1 * more fixes * fix typo * Update e2e-versions.yml * add unit-tests * remove debug info from tests * debug pre-cached versions * change e2e tests to ubuntu-latest * update npm licenses Co-authored-by: George Adams <george.adams@microsoft.com> Co-authored-by: Konrad Pabjan <konradpabjan@github.com> Co-authored-by: Dmitry Shibanov <dmitry-shibanov@github.com>	2021-04-05 13:02:27 +03:00