You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@grails.apache.org by GitBox <gi...@apache.org> on 2026/10/21 01:09:08 UTC

[GH] (grails-core/fix/forge-command-spec-stderr): Workflow run "CI - Groovy Joint Validation Build" is working again!

The GitHub Actions job "CI - Groovy Joint Validation Build" on grails-core.git/fix/forge-command-spec-stderr has succeeded.
Run started by GitHub user jdaugherty (triggered by jdaugherty).

Head commit for run:
2ecd9284bb42652f4cb51310e8926e09484a6ec9 / James Daugherty <jd...@jdresources.net>
Read the generated build's stderr in the Forge command specs

Gradle writes a build's failure report to stderr, and CommandSpec drained only stdout. A generated
build that failed while configuring had nothing to show on stdout, its report went to a pipe nobody
read, and once that report outgrew the pipe buffer (64 KiB on Linux, which a -S trace exceeds
easily) the Gradle client blocked on the write and never exited. The spec then waited out its whole
600s budget and reported the build as still running, with two lines of daemon preamble as the only
output, and the reason the build failed was lost with the process.

Merge stderr into the stream the consumer thread drains. A failed build now exits at once, and its
report is part of the assertion message. CommandSpecBuildFailureSpec covers the case with a
generated project whose build fails while configuring with a report larger than the pipe buffer:
against the old harness it times out after 600s exactly as CI did, and now the build is reported as
exited with code 1 with the failure in the message.

Seen on the "Build Grails Forge (17)" job of pull request #16690, where
CreateControllerCommandSpec."test app with controller" timed out this way.

Report URL: https://github.com/apache/grails-core/actions/runs/39501629731

With regards,
GitHub Actions via GitBox