jdaugherty opened a new pull request, #16645: URL: https://github.com/apache/grails-core/pull/16645
CI jobs keep failing on single downloads that should have come from the Gradle cache, such as `kotlin-bom` 2.4.0 while resolving the settings plugins on Windows, and the JaCoCo agent jar on Ubuntu JDK 25. Both artifacts exist; the jobs had no cached copy and one request to Maven Central or the plugin portal failed. Gradle treats a "not found" as an answer rather than a network error, so it does not retry. The cache is thrashing. On 2026-10-14 the repository held 10.42 GiB of Actions cache against GitHub's 10 GB limit, and the oldest surviving entry was two and a half hours old. Every caching `setup-gradle` step writes an entry on each branch push, about 25 entries and 3.5 GiB per push on 8.x, so three pushes fill the cache and evict everything else. Only Linux entries for 8.0.x, 9.0.x and 9.1.x survived; there were none for Windows, macOS, 8.1.x or 7.x, so those jobs start from an empty Gradle User Home. A job whose own entry was evicted also falls back to any entry whose job id it prefixes, so the core `build` job restored the `buildForge` job's cache, which lacks artifacts only the core build uses. ### Changes Three commits, so that 7.x carries the same caching as 8.x and the fix reaches every branch through the merge-up: - **Use the Grails Develocity access key for the remote build cache.** Backport of #16613: the workflows pass `GRAILS_DEVELOCITY_ACCESS_KEY`, including the Forge AWS deployment, which passed none, and the root, build-logic, grails-forge and grails-gradle settings set `projectId = 'grails'` and push to the remote build cache only when an access key is present. - **Cache the Gradle User Home through setup-gradle instead of actions/cache.** Backport of #16618: the CI workflow's twelve explicit dependency-jar `actions/cache` steps are gone, and every `setup-gradle` step uses the default enhanced provider instead of `cache-disabled` or `cache-provider: basic`. The pinned `setup-gradle` release stays v6.3.0 on 7.0.x. Release verification stays uncached. - **Write the Gradle User Home cache from one core build job per OS.** Only the core `build` job writes, from the matrix entries flagged `cache_writer`: Ubuntu on the branch's baseline JDK and Windows. Every other caching step is `cache-read-only: true` and restores the newest entry for its OS, which setup-gradle falls back to after the job's own keys, then downloads whatever that entry lacks. This is the arrangement setup-gradle's documentation recommends under "Select which jobs should write to the cache". Release runs, whose entries are scoped to the tag, are read-only too. macOS stays read-only to keep within the budget, so it remains a cold build as it is today. Expected effect: roughly two entries per branch push instead of about 25, so each active release branch keeps a Linux and a Windows entry, and pull requests restore their base branch's entry instead of starting empty. Jobs other than the core build re-download the dependencies the core build does not use, which they already do whenever their own entry has been evicted. ### Merge-up to 8.0.x and later 8.0.x already has the first two commits, so the merge keeps its side of those. The third needs the same treatment applied to the 8.0.x-only parts: the `cache_writer` flags on 8.0.x's `build` matrix (Ubuntu JDK 21 and one Windows shard), and `cache-read-only: true` for the jobs and workflows 7.0.x does not have, such as `buildLogic`, `buildRerunTasks`, benchmark, code analysis, coverage, end-to-end, the Groovy snapshot canary, SiteMesh 2 and validate-actions. Once this has reached the active branches, deleting the existing entries with `gh cache delete --all --repo apache/grails-core` lets the new writers start from an empty cache instead of waiting for the old entries to age out. ### Verification - Every workflow parses as YAML, and a parse of all `setup-gradle` steps shows that only the core `build` job's `ubuntu-latest/17` and `windows-latest/25` entries can write; release verification stays uncached. - `./gradlew help` evaluates the changed settings for the root (with build-logic), grails-gradle and grails-forge builds. - The workflows themselves can only be exercised by CI: this pull request's runs are read-only, so the writer path runs on the first push to 7.0.x after merge. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
