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>
GitHub Actions for Gradle builds
This repository contains a set of GitHub Actions that are useful for building Gradle projects on GitHub.
Note
⚡️ Choice of caching providers in v6
To provide the fastest possible build experience this action includes Enhanced Caching via
gradle-actions-caching, an optimized provider powered by proprietary technology. This feature is free for all public repositories and is currently available as a Free Preview for private repositories.Prefer a 100% Open Source (MIT) path? We also provide a Basic Caching provider as a thin wrapper over
actions/cache. This provider is free for all repositories (public and private) and can be enabled at any time by settingcache-provider: basic.For a full breakdown of the components, usage tiers, and our Safe Harbor data privacy commitment, see our Distribution & Licensing Guide.
The setup-gradle action
The setup-gradle action can be used to configure Gradle for optimal execution on any platform supported by GitHub Actions.
This replaces the previous gradle/gradle-build-action, which now delegates to this implementation.
The recommended way to execute any Gradle build is with the help of the Gradle Wrapper, and the examples assume that the Gradle Wrapper has been configured for the project. See this example if your project doesn't use the Gradle Wrapper.
Example usage
name: Build
on:
push:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout sources
uses: actions/checkout@v6
- name: Setup Java
uses: actions/setup-java@v5
with:
distribution: 'temurin'
java-version: 17
- name: Setup Gradle
uses: gradle/actions/setup-gradle@v6
- name: Build with Gradle
run: ./gradlew build
See the full action documentation for more advanced usage scenarios.
The dependency-submission action
Generates and submits a dependency graph for a Gradle project, allowing GitHub to alert about reported vulnerabilities in your project dependencies.
The following workflow will generate a dependency graph for a Gradle project and submit it immediately to the repository via the Dependency Submission API. For most projects, this default configuration should be all that you need.
Simply add this as a new workflow file to your repository (eg .github/workflows/dependency-submission.yml).
name: Dependency Submission
on:
push:
branches: [ 'main' ]
permissions:
contents: write
jobs:
dependency-submission:
runs-on: ubuntu-latest
steps:
- name: Checkout sources
uses: actions/checkout@v6
- name: Setup Java
uses: actions/setup-java@v5
with:
distribution: 'temurin'
java-version: 17
- name: Generate and submit dependency graph
uses: gradle/actions/dependency-submission@v6
See the full action documentation for more advanced usage scenarios.
The wrapper-validation action
The wrapper-validation action validates the checksums of all Gradle Wrapper JAR files present in the repository and fails if any unknown Gradle Wrapper JAR files are found.
The action should be run in the root of the repository, as it will recursively search for any files named gradle-wrapper.jar.
Starting with v4 the setup-gradle action will perform wrapper validation on each execution.
If you are using setup-gradle in your workflows, it is unlikely that you will need to use the wrapper-validation action.
Example workflow
name: "Validate Gradle Wrapper"
on:
push:
pull_request:
jobs:
validation:
name: "Validation"
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: gradle/actions/wrapper-validation@v6
See the full action documentation for more advanced usage scenarios.