When using the “Save and Restore Cache from S3” step to cache Gradle dependencies, restored files and directories are assigned new timestamps rather than preserving the original inode metadata (e.g., access/modification times). This makes it impossible for Gradle to perform cache pruning using built-in mechanisms like:

removeUnusedEntriesAfterDays in DirectoryBuildCache

Directory cleanup via atime with find

gradle_user_home cache maintenance options

As a result, the cache grows rapidly over time—Eugene Kossyak reported growth from 2.8GB to over 5GB within a week—because obsolete or unused dependencies can't be cleaned up effectively. This significantly undermines the value of caching, and in some cases, leads to slower builds than re-downloading dependencies from scratch.

Customer Impact:

This affects customers relying on Gradle’s caching mechanisms to optimize CI performance. Without proper cache pruning, builds slow down, and cache storage grows unsustainably. The current behavior also breaks alignment with Gradle's documented expectations for cache lifecycle management.

Workaround Attempted:

Setting Override Cache = false (intentional, to avoid snowballing caches)

Manual cleanup using find commands (ineffective due to lost inode metadata)

Attempted Gradle-native cleanup options (non-functional for same reason)

Request:

Enhance the drone-cache plugin (underlying the “Save and Restore Cache from S3” step) to preserve inode metadata during archive and restore operations—especially timestamps—so that file-level pruning can function as intended