add Gradle Build Cache support with handler and tests

[matikepa]

• Accepts cache keys at /gradle/{key}
• PUT stores cache entries in storage backend under _gradle/http-build-cache/{key}
• GET returns stored artifact with content type application/vnd.gradle.build-cache-artifact.v2
• HEAD returns headers/metadata without a response body
• PUT returns 201 Created (including first write and overwrite)
• Path traversal and malformed keys are rejected

[andrew]

Can you add a mention to the readme as well?

[andrew]

Thanks for adding the README section.

Bypassing the package database here is the right call. Build cache entries are opaque task-output blobs keyed by input hash, not packages, so there's nothing meaningful to record. But that same property means they churn fast: a busy CI writes hundreds of entries per build and old keys go dead the moment a source file changes. Gradle's own cache node and Develocity both run size-capped or TTL eviction for this reason. As written, _gradle/http-build-cache/ will grow without bound and nothing in the proxy will ever clean it up. I'd like to see an eviction story before this merges, even a simple one: a configurable max-age sweep, or a total-size cap that deletes oldest-first.

Related: handlePut (gradle.go:118) is the first endpoint in this proxy that accepts arbitrary client uploads, and it has no size limit and no auth. Anyone who can reach the proxy can PUT /gradle/anything and fill the storage backend. A configurable http.MaxBytesReader cap on the request body feels mandatory; a config flag to disable PUT (read-only cache mode) would be nice too. Auth can be a follow-up.

Smaller stuff:

• gradle.go:31 NewGradleBuildCacheHandler(proxy *Proxy, _ string) discards its second arg. Drop the param and update the two call sites; unparam will flag this otherwise.
• gradle.go:120 the Exists then Store dance is a TOCTOU and only exists to choose 200 vs 201. Gradle treats any 2xx as success, so drop Exists and always return 201. One fewer storage round-trip per write.
• gradle.go:93 HEAD calls Storage.Open() then never reads. On S3 that's a wasted GetObject. Use Exists + Size for HEAD and only Open for GET.
• gradle.go:140 X-Cache-Size is a custom header Gradle ignores; drop it unless something depends on it.
• gradle.go:128 defer r.Body.Close() is redundant, net/http closes request bodies.
• README points clients at /gradle/ with Kotlin DSL, dashboard.go:296 points at /gradle/cache/ with Groovy DSL. Pick one URL and one DSL for both.

Key validation, path-traversal handling, the _gradle/ storage prefix, and test coverage all look good.

[matikepa]

There is also a potentially missing fallback case: Gradle plugin marker resolution may still be hitting Maven Central instead of the Gradle Plugin Portal, which can lead to 404 errors.

Should I include this fix in the current PR, or open a follow-up PR from a new branch?

—
bit more explanations below:

Technically, Gradle plugin resolution for plugins { id("...") version "..." } does not resolve the implementation artifact directly; it first requests a marker module at coordinate groupId:pluginId.gradle.plugin:version (typically a POM-only artifact).
In our previous flow, /maven artifact fetches were effectively sourced from Maven Central only, so marker requests that exist only in https://plugins.gradle.org/m2 could return 404 even when the corresponding implementation artifact (for example com.diffplug.spotless:spotless-plugin-gradle) was available.

The fix introduces targeted fallback behavior in Maven handling: for Gradle marker-shaped coordinates, if the primary Maven upstream fails, we retry the same path against the Gradle Plugin Portal and cache the result under the same Maven package/version key.
This preserves existing Maven behavior for normal artifacts, unblocks Gradle plugin marker resolution via proxy, and is validated by a live request and regression test using com.diffplug.spotless:com.diffplug.spotless.gradle.plugin:8.4.0 returning 200 and then serving from cache on subsequent calls.

[andrew]

All previous review items addressed. CI green. Code looks good.

Minor things that could be tidied up now or later:

• Blob.ListPrefix fetches individual Attributes when ModTime.IsZero(). The eviction code already handles zero-ModTime entries gracefully, so this fallback could be dropped to avoid N+1 API calls on unusual providers.
• handleGetOrHead calls both Open and Size for GET -- could skip Size and let chunked transfer handle it.
• Filesystem.ListPrefix could use filepath.WalkDir instead of filepath.Walk to avoid extra stat calls.
• PR description says "overwrite returns 200 OK" but code always returns 201. Code is correct, description is stale.

None blocking.

[andrew]

Thanks!