jamesfredley opened a new pull request, #15826: URL: https://github.com/apache/grails-core/pull/15826
## What Raise the per-attempt `timeout_seconds` from `1200` (20 min) to `1800` (30 min) on both publish retry steps in `.github/workflows/gradle.yml` — the `publish` job and the `publishMicronaut` job. ## Why CI run [28709355300](https://github.com/apache/grails-core/actions/runs/28709355300) failed with only the `publish` job red. Tracing the full log of that job (85155475687): - The publish step wraps `./gradlew publish aggregateChecksums aggregatePublishedArtifacts --no-build-cache --rerun-tasks` in `nick-fields/retry` with `timeout_seconds: 1200` / `max_attempts: 3`. - **All 3 attempts hit the 20-minute wall** (`Timeout of 1200000ms hit`). There was **no** `BUILD FAILED`, **no** exception, and **no** Nexus `Read timed out` — a pure per-attempt timeout. - Because of `--no-build-cache --rerun-tasks`, every attempt spins a fresh Gradle daemon and does a full from-scratch recompile + groovydoc/javadoc for 60+ modules + upload to Apache Nexus, which legitimately runs ~14-20 min (the existing comment says *"normal range 14min"*). The last successful publish ([28537677757](https://github.com/apache/grails-core/actions/runs/28537677757)) ran the whole job in **19m48s** — essentially zero headroom. - Recurring ~3-min stalls during Nexus uploads (varying per attempt, so upload latency, not a deadlock) pushed each attempt just past 20 min. Since every retry repeats the identical full uncached build, the retries can't rescue it — they all hit the same wall. Raising the per-attempt timeout to 30 min gives headroom for slow Nexus uploads so a single attempt is not killed mid-publish, while keeping `max_attempts: 3` / `retry_wait_seconds: 180` for genuine transient read-timeouts. Worst case (3 × 30 min + 2 × 180 s waits) is ~96 min, well under the GitHub Actions job limit. ## Notes - CI-config only; no source/behavior change. - The same failed run was also re-run to confirm the diagnosis (transient slow-Nexus timing vs. a persistent defect). -- 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]
