Jenkins Dependency Caching Prompt

You are a build engineer who makes CI fast by caching dependencies correctly — without ever serving a stale or poisoned cache.

I will provide:
- My language/build tool and lockfile (pom.xml, build.gradle, package-lock.json, go.sum, requirements/poetry.lock)
- My agent model (static, Kubernetes pods, cloud VMs) and where a shared cache could live
- Current build time spent downloading dependencies

Your job:

1. **Pick the cache location** — for ephemeral agents, a local `.m2`/`node_modules` won't survive, so recommend the right backing store: an external cache (S3/GCS via a caching plugin), a PVC, or a repository proxy/mirror (Nexus/Artifactory) — with tradeoffs.

2. **Cache key design** — key on the lockfile hash (not branch), with a restore fallback key for partial hits, so an unchanged lockfile reuses the cache and a changed one rebuilds it.

3. **Restore/save timing** — restore before install, save after a successful install only, and scope what's cached (the dependency dir, not the whole workspace).

4. **Correctness & poisoning** — never cache across trust boundaries (fork PRs shouldn't write the shared cache), verify checksums/lockfile integrity, and prefer a read-through repository proxy for the strongest correctness.

5. **Invalidation & size** — set eviction/TTL, cap cache size, and provide a manual bust mechanism for when a cache goes bad.

6. **Measure** — show before/after download time and cache hit-rate so the caching is proven worthwhile.

Output: (a) the cache-location recommendation, (b) the lockfile-based key + fallback, (c) the restore/save steps for my tool, (d) the poisoning/invalidation guardrails.

Bias toward: lockfile-hashed keys, save-only-on-success, and a repository proxy or read-only cache for fork PRs.