jamesfredley opened a new pull request, #16113:
URL: https://github.com/apache/grails-core/pull/16113
## Summary
Reduces Gradle build time on CI and locally without dropping any test
family, matrix leg, or validation.
Opened as a draft so the timing can be measured against the historical
baseline before asking for review. If the CI wall-clock does not actually
improve, this PR will be closed.
## Why
Two sources of avoidable work were measured on `8.0.x`:
1. **CI discarded the remote cache.** Most jobs passed `--rerun-tasks`,
which forces *every* selected task, not just tests. A sampled normal job logged
500+ `FROM-CACHE` outcomes; the forced job logged none. The flag was throwing
away the Develocity benefit purely to guarantee tests actually ran.
2. **A dedicated forced-rerun job sat on the critical path.**
`buildRerunTasks` cost a **78.4 minute median**. Across **253 completed `8.0.x`
runs** it produced no confirmed unique correctness catch (the one apparent
catch was a runner shutdown).
Baseline for comparison: **148.6 min median** for the last 20 successful
push runs, **106.7 min median** across the recent PR cohort.
## Changes
**1. Limit the default local test fork count**
The local default was `availableProcessors * 3/4`, i.e. 15 concurrent JVMs
on a 20-thread machine, which oversubscribed CPU and RAM. Now defaults to 4.
Measured on a 14-core / 20-thread workstation with identical warm inputs and
tests forced:
| Suite | 15 forks | 4 forks |
|---|---|---|
| `:grails-test-suite-web:test` | 114.5s | **79.4s** |
| `:grails-gradle-plugins:test` | 232.0s | **217.7s** |
(2 forks was slower than 4 at 89.1s.) CI defaults are unchanged, and
`-PmaxTestParallel=N` still overrides.
**2. Reuse cacheable build outputs in normal CI runs**
- CI test jobs use `DO_NOT_CACHE_TESTS=1` instead of `--rerun-tasks`: tests
are still forced to execute, but compilation and resource processing stay
cacheable.
- `gradle/spring-security-test-config.gradle` now honours that variable, so
its suites are forced like every other test family. Verified: two consecutive
runs both executed the `Test` task while 209 other tasks stayed up-to-date.
- The whole-build forced rerun moves to a new weekly + `workflow_dispatch`
`gradle-build-validation.yml` running the identical command, so nothing stops
being validated - it just leaves every PR and push.
- Aggregate Groovydoc runs once on the Ubuntu / JDK 25 leg instead of all
four core legs. JDK 25 builds the full graph including the Micronaut island
that a sub-25 JDK prunes, so the documented surface is a superset of what JDK
21 covered. A Groovydoc failure still fails that leg and still blocks
publishing.
**3. Document the controls** in `DEVELOPMENT.md`.
## Verification
- `./gradlew validateActions` - all 24 workflows compliant.
- `./gradlew clean aggregateViolations :grails-test-report:check --continue`
- Checkstyle, CodeNarc, PMD and SpotBugs all report **no violations**.
- Post-change scoped runs green: web suite 78.7s, `grails-gradle` 204.7s,
`:grails-redis:test`, and `:grails-spring-security:test
-PonlySpringSecurityTests`.
- Two full-suite failures were triaged and reproduced in isolation, and
**neither is caused by this branch**:
- `grails-test-examples-mail` - pre-existing Windows-only CRLF assertion
(`Hello\r\nWorld!` vs `Hello\nWorld!`), reproduces identically in isolation.
- `grails-test-examples-spring-security-ui-extended` - Selenium deleted
the shared session after 32s of inactivity under full-repo load; passes all 63
tests in isolation.
## Note for a follow-up
Unrelated to this PR: the existing `-PonlyRedisTests` selector composes
conflicting `onlyIf` predicates, so the `grails-redis` plugin module's unit
tests are skipped in the Redis CI lane even under `--rerun-tasks`. Left alone
here because fixing it would *add* coverage and confound this timing experiment.
--
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]
