Add Gradle cache to official pack pipeline

[PureWeen]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Problem

The official build (dotnet-maui, definition 1095) for release/10.0.1xx-sr6 has been failing with Gradle network errors on Windows:

Permission denied: getsockopt
Could not GET https://repo.maven.apache.org/maven2/...
gradlew.bat exited with code 1

Build 2954057 failed even though it included the Gradle cache fix from PR #35016. The cache step was added to provision.yml, but the official Pack job uses pack.yml directly — which never calls provision.yml.

Fix

Add the same cache-gradle.yml template call to eng/pipelines/common/pack.yml before the pack step, matching the pattern already used in provision.yml.

Impact

This unblocks the 10.0.60 official build by ensuring the Gradle dependency cache is warm before the Pack step invokes Gradle on Windows agents with network isolation.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35049

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35049"

[Copilot]

Pull request overview

Adds Gradle dependency caching to the shared pack.yml pipeline template so official pack jobs warm/restore the Gradle cache before invoking the pack step (helping avoid transient Maven/Gradle network failures on Windows agents).

Changes:

• Invoke the existing shared cache-gradle.yml template from eng/pipelines/common/pack.yml before the pack build runs.

[jonathanpeppers]

Does this share the cache between all OSs? I don't know if their cache is cross-platform.

[PureWeen]

Replying to @jonathanpeppers' question on the cross-OS fallback key ("gradle" | "v1" on line 41):

Short answer: The Gradle dependency cache is mostly cross-platform, but not entirely. The fallback is a best-effort warm start, not a guaranteed full restore.

What works cross-OS:

• Downloaded JARs, POMs, AARs in caches/modules-2/files-2.1/ — these are byte-identical across platforms (kotlin-stdlib, AndroidX, Gradle plugins, etc.). This is the bulk of the 1.2 GB cache.
• Gradle's dependency cache uses relative paths internally, so file location differences aren't an issue.

What doesn't work cross-OS:

• aapt2 uses OS-specific Maven classifiers (aapt2-*-osx.jar vs aapt2-*-windows.jar). Gradle resolves by classifier, so it would not try to use the macOS binary on Windows — it would attempt to download the Windows variant (which would fail under CFSClean anyway).
• caches/transforms-*/ and caches/jars-*/ (script caches) — Gradle gracefully regenerates these on cache miss, so stale entries don't cause failures.
• .lock files — Gradle handles stale locks gracefully.

Net effect: The cross-OS fallback gives Windows a warm start with ~95% of the dependencies pre-cached (all the pure Java artifacts). OS-specific artifacts (aapt2) would still need to be resolved. This is strictly better than a complete cache miss, and Gradle handles the incompatible entries gracefully (cache miss → regenerate, not crash).

That said — in practice, this build currently only has a Pack macOS job (no Pack Windows), so the cross-OS fallback isn't actually being exercised today. If a Windows Pack job is added in the future and CFSClean is still blocking Maven Central, the fallback alone won't be sufficient (aapt2 download would still fail). A Windows-specific cache would need to be populated separately, or aapt2's Maven domain would need to be allowlisted.

Happy to remove the cross-OS key if you think the partial-restore behavior is more confusing than helpful. The OS-specific keys ("gradle" | "v1" | "$(Agent.OS)") are the ones doing the real work.

---

Cross-checked with Sonnet 4.6, Codex 5.3, and Opus 4.6 — all agree the dependency artifacts are portable but OS-specific binaries (aapt2) are not. Gradle self-heals on incompatible cache entries rather than crashing.

[jonathanpeppers]

The general idea of restoring the cache here would improve this pipeline, for sure.

[PureWeen]

/backport to main

[github-actions]

Started backporting to main (link to workflow run)