jdaugherty opened a new pull request, #16618:
URL: https://github.com/apache/grails-core/pull/16618
## Description
Every Gradle job restored and saved `~/.gradle/caches/modules-2` and
`~/.gradle/wrapper` through an explicit `actions/cache` step keyed by branch
and dependency hash, and disabled the cache that `setup-gradle` manages. That
scheme was adopted in July to stay under GitHub's 10 GB cache quota, but its
restore and save steps have been timing out repeatedly, and the quota is full
anyway: every pull request that missed the exact key saved its own 0.5 to 0.8
GB copy scoped to that pull request, which nothing else can read. Seven such
copies hold 4.5 GB of the 10.4 GB in use today, and the 8.1.x and 7.x branch
entries have already been evicted.
This returns to `setup-gradle`'s own caching, as the workflows were
originally configured, now with its default `enhanced` provider. The pinned
release (v6.4.0) is unchanged.
### Two cache layers
- **Gradle User Home** (dependencies, wrapper distributions, transforms):
`setup-gradle`'s enhanced provider, stored in GitHub's cache. It keeps
fine-grained, content-keyed bundles that every job in the same scope shares,
and removes unused files before saving, which addresses the quota concern
behind the explicit steps. It is free for public repositories. The
vulnerability scan workflow has run on it since it was added; its
full-repository resolution on 8.0.x occupies about 0.65 GB, with a 1 MB per-job
entry.
- **Task outputs**: the Develocity remote build cache on
develocity.apache.org, which the Gradle build pushes to when the access key
`setup-gradle` exports is present, working again since #16613. Every step still
passes the key.
### Write policy
The provider only writes from the repository default branch unless told
otherwise. With 8.0.x as the default, every other release branch would read
8.0.x's entries and never save its own. Each caching `setup-gradle` step
therefore sets:
```yaml
cache-read-only: ${{ github.event_name == 'pull_request' }}
```
GitHub scopes entries by ref, so each release branch keeps its own set. Pull
requests read their base branch's entries, then the default branch's, and do
not write, since their entries would be visible to that pull request alone. A
release runs on its tag: GitHub lets it read the default branch's entries but
not its release branch's, and what it writes serves a re-run of the same
release. The `cache_writer` matrix flags and the split restore/save steps are
no longer needed.
### What remains in GitHub's cache
- The Gradle User Home entries `setup-gradle` manages.
- The mongod download the embedded MongoDB tests run, which lives outside
the Gradle User Home.
### Exceptions
- `release-verify.yml` stays uncached, as before.
- The Groovy snapshot canary's Groovy build job is now cached: Groovy is
rebuilt each run, but its build dependencies are not, and the entry is keyed by
job.
- No `cache-encryption-key` is set, so configuration-cache state is not
cached. That can be a follow-up.
### Verification
- All workflow files parse, and `validateRepositoryConventions` and
`validateActions` pass.
- CI on this pull request runs in read-only mode, so it demonstrates
restores and the removal of the old steps, not writes. The first writes happen
on the 8.0.x push after merge; the Setup Gradle post-job summary lists the
entries saved, and the Develocity build scan shows remote cache stores.
- After merging, `gh cache delete --repo apache/grails-core --all` clears
the old `gradle-deps-*` and `setup-java-*-gradle` entries at once instead of
waiting seven days for them to age out, at the cost of one cold run per branch
and job.
--
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]
