jdaugherty opened a new issue, #16388: URL: https://github.com/apache/grails-core/issues/16388
### Issue description Using AI to analyze our publish process has identified some possible clean-ups we should do to get faster publishing: Yes — there's a lot of fat in that job. I profiled it against the last completed release (M6, 71 min total) and dry-ran today's task graphs locally to confirm the findings still hold on 8.0.x. Where the time actually goes Current RC1 run so far: validateDependencyVersions 5:06, assemble 47:01. M6's full breakdown: ┌─────────────────────────────────────────────┬────────────────────┐ │ step │ time │ ├─────────────────────────────────────────────┼────────────────────┤ │ 🧩 grails-core assemble │ 41:48 │ ├─────────────────────────────────────────────┼────────────────────┤ │ 📤 Publish Grails Core to Staging │ 13:16 │ ├─────────────────────────────────────────────┼────────────────────┤ │ 🔍 Validate dependency versions │ 3:40 │ ├─────────────────────────────────────────────┼────────────────────┤ │ micronaut / forge / gradle-plugin publishes │ 2:54 / 1:54 / 1:51 │ ├─────────────────────────────────────────────┼────────────────────┤ │ forge assemble │ 2:51 │ ├─────────────────────────────────────────────┼────────────────────┤ │ everything else │ < 1:00 each │ └─────────────────────────────────────────────┴────────────────────┘ Findings, biggest first 1. assemble builds all 114 example apps — 47% of the task graph, for artifacts that are never published. ./gradlew assemble (release.yml:96) runs assemble in every project. Dry-run on 8.0.x today: 3967 tasks, of which 1850 belong to grails-test-examples-* — bootJar, assetCompile, compileGroovyPages, generateTagLibraryIndex, plus a javadoc+javadocJar+sourcesJar per app. Restricting to the publishedProjects list already in gradle/publish-root-config.gradle:26 gives 1911 tasks, zero example projects, and still produces the wrapper distZip the next step signs. That's the single biggest win — order of 15–20 minutes. 2. The assemble step is largely redundant with the publish step anyway. publishToSonatype dry-runs to 3671 tasks including every jar/javadocJar/sourcesJar and no example projects. Assemble's real job is (a) the wrapper zip for the pre-staging GitHub upload and (b) failing fast. Narrowing it per #1 keeps both. 3. 134 modules compile their entire test source set for a jar that is never published. signMavenPublication → testSourcesJar → testClasses → compileTestJava/compileTestGroovy, for every module. But only grails-datamapping-core-test sets pomPublishTestSources = true, and it's the only module with a -tests.jar on Central — grails-core and grails-validation have only sources/javadoc. ~4 min, all waste. Fix belongs in the external grails-publish plugin (register/wire testSourcesJar only when publishTestSources is set). 4. GPG signing forks a gpg process per signature — 5:21 of the 13:16 core publish. The workflow exports SIGNING_KEY but not SIGNING_KEYRING, so grails-publish falls back to signing.gnupg.keyName (its own message: "No keyring file (SIGNING_KEYRING) has been specified. Assuming the use of local gpgCommand"). Supplying SIGNING_KEYRING + SIGNING_PASSPHRASE switches to the in-JVM BouncyCastle signatory, which is much faster and parallelises inside the daemon. 5. The release job starts with a completely cold Gradle cache. From the log: Basic caching did not find an entry to restore. Will start with empty state. Remote build cache is off by design (settings.gradle:66, SOURCE_DATE_EPOCH), and setup-gradle is read-only with no hit because the run is on a tag. gradle.yml:40 has an explicit actions/cache for ~/.gradle/caches/modules-2; release.yml has none, so every dependency is re-downloaded. Caveat: a tag-ref run can only read caches from the default branch, so this needs a key that a default-branch run actually writes — worth checking before investing. 6. Split the job. findSonatypeStagingRepository locates the repo by description, so once "Create Staging Repository" has run, the gradle-plugins / core / forge publishes (and the docs smoke-check) can be parallel jobs rather than a 25-minute serial tail. Costs artifact passing for the combined checksums. Not a problem: javadoc is already disabled for published modules (130 disabled, and 115 of the 152 still enabled are example apps — covered by #1). javadocJar packages only groovydoc output, confirmed by probing javadocJar.source. -- 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]
