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>
This commit is contained in:
Julien Dubois
2026-08-05 17:57:27 +02:00
committed by GitHub
parent ab597f914a
commit f4bfb3ddea
20 changed files with 1037 additions and 66 deletions
+15 -1
View File
@@ -248,7 +248,8 @@ describe('JDK resolution cache', () => {
algorithm: 'sha512',
value: 'def456',
source: 'https://example.com/a.sha512'
}
},
floating: true
};
restoreWith(JSON.stringify(full), 'setup-java-jdkres-v1-old');
@@ -312,6 +313,19 @@ describe('JDK resolution cache', () => {
state.length
);
});
it('uses different keys for different floating artifact identities', () => {
createRunnerTemp();
registerJdkResolution({...request, source: 'sha256:first'}, release);
registerJdkResolution({...request, source: 'sha256:second'}, release);
const state = JSON.parse(
jest.mocked(core.saveState).mock.calls.at(-1)![1] as string
);
expect(new Set(state.map((item: {key: string}) => item.key)).size).toBe(
state.length
);
});
});
describe('saveJdkResolutionCaches', () => {