jamesfredley commented on code in PR #16167:
URL: https://github.com/apache/grails-core/pull/16167#discussion_r3934558385
##########
.github/workflows/gradle.yml:
##########
@@ -142,6 +142,16 @@ jobs:
java: 21
job_name: macOS JDK 21
gradle_task: 'build :grails-shell-cli:installDist groovydoc'
+ # The macOS runner has ~7 GB of RAM and 3 CPUs, against ~16 GB and
4 CPUs on the
+ # Linux and Windows runners, while org.gradle.jvmargs still asks
for a 5 GB daemon
+ # (groovydoc needs it). Capping only maxTestParallel would not
help: that is a
+ # per-Test-task limit, and with org.gradle.parallel=true several
projects' test
+ # tasks run at once, so the number of live forks is bounded by
Gradle's global
+ # worker pool - which defaults to the 3 CPUs here. --max-workers
is therefore the
+ # setting that actually limits concurrent test and compiler JVMs;
maxTestParallel
+ # is kept alongside it so no single task exceeds that cap either.
This reduces
+ # memory pressure on the smallest runner rather than proving the
job fits.
+ runner_arguments: '--max-workers=2 -PmaxTestParallel=2'
cache_writer: true
- os: windows-latest
java: 25
Review Comment:
Not valid. GitHub Actions interpolates a missing matrix property as an empty
string (see the contexts reference: "If you attempt to dereference a
nonexistent property, it will evaluate to an empty string").
This workflow already depends on that: `matrix.shard_arguments` is only set
on the Windows shards, and Ubuntu/macOS still `${{ matrix.shard_arguments }}`
today. This PR's own CI ran the Ubuntu and Windows jobs without
`runner_arguments` defined; they did not fail at expression evaluation.
Leaving the other rows undefined matches the existing `shard_arguments`
pattern. No change.
--
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]
