I reviewed this against a fix I'd written independently for #1209 and ended up preferring your approach, so rather than open a competing PR I've pushed one test-only commit here (3b8f519). Happy to drop it if you'd rather keep the branch yours.

What the commit adds

Two gaps in platform-types.ts coverage:

• getJavaPlatformIdentity's normalizePlatform(platform) ?? platform fallback had no test — the it.each covered only linux/darwin/win32, which all hit the alias map. Added sunos → solaris (alias path) and aix → aix (fallback path).
• isAlpineLinux had no direct test, so its platform === 'linux' short-circuit was unpinned.

Both verified by mutation rather than by eyeballing coverage:

The short-circuit one is worth pinning beyond coverage bookkeeping: it's 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.

Full suite is green (41 suites / 1322 tests), format-check and lint clean. Test-only, so no dist/ rebuild.

On the design

My version used a protected getResolutionPlatform() hook on JavaBase that each distribution overrode to return its own getPlatformOption(). I talked myself into it on the grounds that it can't drift from artifact selection — but checking it against this branch, yours is the better design and the hook is unnecessary.

The hook only protects distributions that remember to override it, so its failure mode is a silent cross-libc collision — the exact bug in #1209. Yours is correct by default for every distribution, including ones that don't participate. I also couldn't find a single distribution that would need to override it today: identity is a function of (platform, arch, packageType, versionSpec, stable), and I checked the one candidate I suspected — Temurin's includeJmods — which derives from packageType and is therefore already covered. Even if Dragonwell/Corretto were later fixed to select alpine-linux artifacts, your identity already separates those correctly. So it'd be an abstraction with zero users.

Your injectable-parameter signature is also strictly better for testing than what I had, which mutated process.platform and spied on fs.

Two optional notes

The v1 → v2 bump is redundant, if you'd prefer to avoid the test churn. The restore key is ...-v{N}-{os}-{arch}-{digest}- and the cache path embeds the digest too, so adding platform to the hashed object already changes the digest — no v1 entry can match the new prefix, and @actions/cache's path-derived version check is a second layer. Harmless as intent-signalling, just not load-bearing. Maintainer call.

Minor: expectedRequest in base-installer.test.ts builds its expectation by calling getJavaPlatformIdentity(), the same function the production path calls. It still proves the wiring (a missing or wrong field fails), and the helper's behaviour is well covered by the contract tests, so this is fine as-is — just flagging that the assertion can't catch a regression inside the helper.

Out of scope, for the record

Dragonwell and Corretto publish alpine-linux artifacts but their getPlatformOption() returns plain linux on Alpine, so they resolve glibc artifacts on musl runners. That's a pre-existing artifact-selection bug, unrelated to cache identity, and this PR neither causes nor worsens it. Worth a separate issue.

Status: this is merge-ready — all 84 checks green (one unrelated Windows GPG-cleanup flake re-run), branch up to date with main, and I've approved it.

It can't actually merge yet, though: the Copilot Code Review ruleset sets require_last_push_approval: true, and I pushed the last commit (3fc4744). That commit is a production change, not just tests — merging main brought in #1219, whose getFloatingResolutionRequest predates the required platform field, so the merged tree didn't compile and dist/ was stale.

So it needs an approving review from someone who didn't make that push — @jdubois or another maintainer. I'd rather leave it for a second pair of eyes than bypass the rule, especially since my commit touches base-installer.ts.