jamesfredley commented on PR #16337:
URL: https://github.com/apache/grails-core/pull/16337#issuecomment-6001304265
Benefits of Folding it in.
Keeping it separate added a second set of build files to keep in sync, a
second publish job, and a publish step in front of every Forge test.
### 1. A separate Forge build would have depended on the root build anyway
The old `grails-forge/settings.gradle` pulled the framework in with
`includeBuild('..')`. Every Forge invocation therefore did three things:
1. compiled Forge's own `buildSrc`
2. configured the whole root build as an included build
3. configured the seven Forge projects on top of it
Folding removes the first and third layers and keeps the one you already
paid for. The objection "now Forge pays for configuring the monorepo" does not
hold, because it already did.
The isolation people want from a third build still exists. Core CI passes
`-PonlyCoreTests`, which disables every task on the seven Forge projects. Core
shards do not compile, package, or test Forge.
### 2. One set of build files instead of two
As a third build, Forge had its own `settings.gradle`, `gradle.properties`,
Gradle wrapper, and `buildSrc`. Every Gradle bump, dependency pin, and CI cache
change had to land in both places. That is not hypothetical. When this branch
moved to `9.0.x`, the conflicts were exactly those files:
- `grails-forge/settings.gradle`
- `grails-forge/gradle.properties`
- `grails-forge/buildSrc/build.gradle`
- the Forge wrapper jar, properties, and `gradlew.bat`
`9.0.x` had kept editing them while the framework moved on. After the fold,
Forge's Rocker and shadow plugins live in `build-logic` with the other
convention plugins. Versions come from the same `dependencies.gradle` and
`grails-bom` as everything else.
### 3. Forge stays on the same version as the framework it generates
Forge generates Grails 9 applications, and after this PR it is itself a
Grails application. It should compile against, test against, and ship with the
same Groovy and Spring line as the framework release it belongs to.
As a root subproject it gets Groovy 6.0.0 from `grails-bom` automatically.
As a third build, that alignment was a manual step, and on this branch it had
drifted (the PR still described Groovy 5.1.2).
### 4. Normal Forge tests no longer publish the whole repository first
The old Forge build made every `Test` task depend on publishing all of the
root build and all of `grails-gradle` into `build/local-maven`. That included
suites that never generate an application.
Now only the two TestKit projects (`grails-forge-cli` and
`grails-forge-test-core`) do that publish, because only they generate apps.
Locally, `:grails-forge-core:test` ran 377 specs in 28.3 seconds with no
publish in front of it. That is the main day-to-day developer win.
### 5. One publish instead of two
The last successful `9.0.x` push ([run
37072297447](https://github.com/apache/grails-core/actions/runs/37072297447))
ran a separate `publishForge` job:
- **6.0 minutes** of runner time
- its own checkout and Gradle startup
- its own configure of the root build through the nested build
- a second `--rerun-tasks` publish taking **5.6 minutes**
`verifyWrapper` had to wait for it. Folded, Forge publishes in the existing
publish job with the rest of the repository, as one release unit, and that
extra job is gone.
### 6. Root-level checks reach Forge without a second invocation
Running `validateDependencyVersions`, violation aggregation, or a release
build used to mean running the same command a second time from `grails-forge/`.
As root subprojects, Forge projects are part of the same task graph as
everything those checks already cover.
### What the argument does not claim
The three Forge test jobs (**40.8 to 48.4 minutes** on that run) still run.
Their command now uses the root wrapper.
The 6 minutes from `publishForge` ran in parallel with the 25.6-minute docs
job, so that run did not end sooner. The gain there is runner time, not total
workflow time.
The case for folding is mostly structural. A third build already depended on
the whole root build, so it duplicated build files and publish work without
giving any isolation that `-PonlyCoreTests` does not already give.
--
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]
