Restore dependency and wrapper caches concurrently

[brunoborges]

Description:
This reduces setup time for cache-enabled Maven and Gradle jobs by running independent restore operations in parallel instead of serially. The change preserves current behavior for outputs, optional wrapper cache skipping, and post-job save sequencing, while tightening failure handling so wrapper save failures do not block the main dependency cache save.

Implementation highlights:

• Compute main and additional wrapper cache keys concurrently, persist restore state first, then restore caches concurrently.
• Keep cache-primary-key and cache-hit semantics tied to the primary dependency cache.
• Keep wrapper uploads sequential, and continue saving the primary cache if an unexpected additional-cache save fails.
• Add restore-miss logging for wrapper caches and cache-specific Gradle daemon warning text for additional caches.
• Extend unit tests for concurrency behavior and primary-save continuation on additional-cache failure.
• Extend cache E2E coverage to assert wrapper cache artifacts in both standard and cache-dependency-path Maven/Gradle restore flows.
• Add a manual benchmark workflow plus helper script to compare baseline vs candidate restore wall time across Linux, macOS, and Windows.

Fixes: #1171

Related issue:
#1171

Check list:

• Ran npm run check locally (format, lint, build, test) and all checks pass.
• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[Copilot]

Pull request overview

This PR reduces setup-java cache-enabled Maven/Gradle setup time by restoring the primary dependency cache and independent wrapper caches concurrently, while preserving primary-cache outputs/semantics and improving resilience when additional-cache saves fail.

Changes:

• Restore primary dependency cache and additional wrapper caches in parallel after concurrently computing cache keys and persisting restore state.
• Add wrapper-cache restore-miss logging and make additional-cache save failures non-blocking for the primary cache save.
• Extend unit/E2E coverage and add a manual benchmark workflow + helper script to compare sequential vs concurrent restore wall times.

Show a summary per file

File	Description
src/cache.ts	Implements concurrent key computation + concurrent restore for primary/additional caches; adjusts save error handling and logs.
dist/setup/index.js	Bundled build output reflecting the new restore/save behavior (setup entrypoint).
dist/cleanup/index.js	Bundled build output reflecting the new restore/save behavior (post/cleanup entrypoint).
.github/workflows/e2e-cache.yml	Extends cache E2E workflow to assert wrapper cache artifacts are restored for Maven/Gradle flows.
.github/workflows/benchmark-cache-restore.yml	Adds a manual benchmark workflow to compare baseline vs candidate cache restore wall time across OSes/tools/profiles.
tests/cache/maven/.mvn/wrapper/maven-wrapper.properties	Adds Maven wrapper properties fixture for wrapper-cache keying in tests/E2E.
tests/cache/gradle1/gradle/wrapper/gradle-wrapper.properties	Adds Gradle wrapper properties fixture for wrapper-cache keying in tests/E2E.
tests/cache.test.ts	Adds concurrency-focused unit tests and coverage for continuing primary save after additional-cache failure.
tests/benchmark-cache-restore.sh	Adds helper script used by the benchmark workflow to prepare/reset/populate/record/summarize timings.

Review details

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comments suppressed due to low confidence (1)

.github/workflows/e2e-cache.yml:317

• Step name says the Maven Wrapper cache "has been made" in the restore job, but this job is validating that the wrapper cache was restored from the previous save. The wording is misleading and inconsistent with the earlier maven-restore job step name.

      - name: Confirm that the Maven Wrapper cache has been made

• Files reviewed: 7/9 changed files
• Comments generated: 1
• Review effort level: Low