Add Windows coverage for caching via a new smoke-test suite - #1027
Merged
Conversation
Issue #1013 revealed that caching was never storing content on Windows. The integ-tests lost their multi-OS matrices at some point, so nothing exercised the Windows code path. Extract the two cheapest caching tests (restore-gradle-home and basic-cache-provider) into a new 'suite-smoke-test-caching' workflow and run it against both ubuntu-latest and windows-latest in CI-integ-test-full. Both tests seed a cache and then verify it with an --offline build, so a cache that never stores content fails the verify job. - Rename integ-test-{restore-gradle-home,basic-cache-provider} to smoke-test-* and drop them from suite-integ-test-caching - Add the new suite to both CI-integ-test and CI-integ-test-full, with its own concurrency group to match the sibling suites - Include smoke-tests in the integ-test-success aggregate gate - Ignore the generated task-configured.txt marker in workflow-samples Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Run the caching smoke-test suite against windows-latest in CI-integ-test, not just CI-integ-test-full, so the Windows cache-store failure from #1013 is visible on a PR and the fix can be verified the same way. Also drop the dead 'determine-suite' guard on the build-distribution step: CI-integ-test has no such job, so the expression always evaluated to true. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bigdaz
added a commit
that referenced
this pull request
Aug 1, 2026
) 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>
This was referenced Aug 2, 2026
bigdaz
added a commit
that referenced
this pull request
Aug 2, 2026
Partial revert of the extraction in #1027. The caching smoke test should answer one question quickly: does a seeded cache let a later build run --offline? Everything else is integration-level. smoke-test-restore-gradle-home now has just two jobs: seed the cache, then verify --offline. The build-cache, no-extracted-cache-entries-restored and pre-existing-gradle-home jobs move to a restored integ-test-restore-gradle-home, wired back into suite-integ-test-caching. That file is identical to the pre-#1027 original except for the dependencies-cache job, which the smoke test now owns. The seed-build job is intentionally duplicated across the two workflows. They use distinct cache keys, since both suites run concurrently and would otherwise write to the same entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bigdaz
added a commit
that referenced
this pull request
Aug 2, 2026
…#1032) Partial revert of the extraction in #1027. The caching smoke test should answer one question quickly — does a seeded cache let a later build run `--offline`? Everything else is integration-level. Replaces #1031 and #1030, squashed into a single commit. ## Layout `smoke-test-restore-gradle-home.yml` — two jobs: | job | purpose | |---|---| | `restore-gradle-home-seed-build` | seed the cache | | `restore-gradle-home-dependencies-cache` | verify the restored cache allows `--offline` | `integ-test-restore-gradle-home.yml` — restored, wired back into `suite-integ-test-caching`: | job | purpose | |---|---| | `restore-gradle-home-seed-build` | seed the cache (duplicated, see below) | | `restore-gradle-home-build-cache` | local build-cache restored | | `restore-gradle-home-no-extracted-cache-entries-restored` | build works with cache entries skipped | | `restore-gradle-home-pre-existing-gradle-home` | pre-existing GUH overwritten by restore | This file is identical to the pre-#1027 original except for the `dependencies-cache` job, which the smoke test now owns. All four jobs keep the `runner-os` matrix. ## Notes **The seed job is duplicated, with distinct cache keys.** The smoke suite uses `smoke-test-restore-gradle-home-*`; the integ suite keeps `restore-gradle-home-*`. This matters: `smoke-tests` and `caching-integ-tests` run concurrently in `ci-integ-test.yml`, so sharing a key would have both suites racing to write the same entry. **Distinct workflow `name:`.** The smoke workflow is `Smoke test restore Gradle Home`, so the two don't appear identically in the Actions UI. **One thing to be aware of for the future:** `restore-gradle-home-pre-existing-gradle-home` cannot pass on Windows. Pre-creating `~/.gradle` is what stops `setup-gradle` relocating the Gradle User Home to `D:\a\.gradle`, so the job looks for a cache entry rooted at a different path than the seed build saved and never matches it. The caching integ suite runs ubuntu-only, so this is not a problem today — but adding Windows to that suite would surface it. ## Verification All workflow YAML parses, and every local `uses:` reference resolves — no dangling paths after the rename and re-add. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Issue #1013 revealed that caching was never storing content on Windows. Nothing caught it because the integ-tests lost their multi-OS matrices: these workflows used to default to
'["ubuntu-latest", "windows-latest", "macos-latest"]', narrowed to ubuntu-only in bcd07e6 / d74ee73 (Aug 2024). The Windows code path has been dark ever since.What
Extract the two cheapest caching tests —
restore-gradle-homeandbasic-cache-provider— into a newsuite-smoke-test-cachingworkflow, and run that suite on bothubuntu-latestandwindows-latest.Both tests seed a cache in one job and then verify it in a dependent job with an
--offlinebuild, so a cache that stores nothing fails the verify job rather than passing silently.integ-test-{restore-gradle-home,basic-cache-provider}→smoke-test-*and drop them fromsuite-integ-test-cachingCI-integ-testandCI-integ-test-full, each with its own concurrency group matching the sibling suitessmoke-testsin theinteg-test-successaggregate gatetask-configured.txtmarker inworkflow-samplesneeds.determine-suiteguard on thebuild-distributionstep —CI-integ-testhas no such job, so it always evaluated to trueThe suite runs on Windows in PR CI (not just
CI-integ-test-full) specifically so the failure is visible on this PR and the fix can be verified the same way.Expected result
This PR is expected to be red on Windows.
restore-gradle-home-dependencies-cacheandbasic-cache-verify-buildshould fail with dependency-resolution errors under--offline— that is the bug from #1013 being caught. The ubuntu legs should stay green.Cross-OS cache keys are safe: both providers include
RUNNER_OSin the key (sources/src/cache-service-basic.ts:146), so the matrix legs don't collide.🤖 Generated with Claude Code