mirror of
https://github.com/gradle/actions.git
synced 2026-08-17 11:22:50 +00:00
79b19cd50f
Follow-up to #1027, which added Windows coverage for the caching smoke tests. `basic-cache-verify-build` failed on Windows for a reason unrelated to #1013. ## Root cause The Windows seed job **never uploaded a cache entry, but reported that it did**. `gh cache list` showed no `setup-java-Windows-*` entry at all, despite the job logging `Basic caching saved entry with key: setup-java-Windows-x64-gradle-594edf…`. The keys were never the problem — seed and verify requested the identical key. The seed build leaves a Gradle daemon running, holding the `*.lock` files in the Gradle User Home. On Windows those locks are mandatory, so `tar` cannot read them: ``` /usr/bin/tar: ../../.gradle/caches/modules-2/modules-2.lock: Read error at byte 0, while reading 38 bytes: Device or resource busy /usr/bin/tar: Exiting with failure status due to previous errors ``` 38 bytes is exactly Gradle's lock-file header — the region the daemon holds via `FileChannel.lock()`. On Linux the lock is advisory and tar reads straight through, which is why this only ever failed on Windows. `cache.saveCache()` catches the tar failure, logs it, and returns `-1` rather than throwing. `BasicCacheService.save()` ignored the return value, so the seed job went green and the failure surfaced only later — as a plugin resolution error in the verify job, pointing nowhere near caching. ## Changes **1. Warn when the save fails.** Check the returned `cacheId` and, when it is `-1`, emit a warning and report `(Entry not saved: save failed)` in the job summary. Caching failures still do not fail the build. **2. Run the seed build with `--no-daemon`.** Daemon management for enhanced caching lives in the `gradle-actions-caching` library; basic caching leaves it to the workflow, so the smoke test now ensures no daemon is holding locks when the post-action save runs. ## Not related to #1013 The enhanced provider fails differently on Windows — every entry dies at path validation, before tar runs (`Path Validation Error: Path(s) specified in the action for caching do(es) not exist`). Same symptom, different mechanism; that one is unchanged here and is still expected to be red. ## Verification `npm run check` and `npm test` pass locally (373 tests). The real check is this PR's Windows run: `basic-cache-seed-build` and `basic-cache-verify-build` should both be green on `windows-latest`, while the `restore-gradle-home-*` Windows jobs stay red pending the #1013 fix. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>