CI: artifact build compiles frontend and backend modules the WAR never contains
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 970
- Forks
- 486
- Avg merge
- 3d 33m
- Merged PRs (30d)
- 170
Description
Problem
The Initial Artifact Build is the serial prefix of every PR run — all ~25 test jobs wait on it. It takes ~14.2m, of which ~7.0m is Maven. A large share of that builds things the dotCMS WAR never contains.
Frontend
core-web runs nx run-many -t build across the whole workspace (2.85m). But the WAR's webResources block lists exactly five paths:
dist/apps/dotcms-ui -> dotAdmin
dist/libs/dotcms-webcomponents/dist
dist/apps/dotcms-binary-field-builder
dist/apps/dotcms-block-editor
dist/libs/sdk/analytics-standalone (its own `build-analytics` execution)
Everything else — sdk-*, ai-evals, dotcdn — is built and discarded. Both SDK publishers (deploy-javascript-sdk, publish-sdk-next) start from a clean checkout and rebuild sdk-* themselves; deploy-javascript-sdk even passes --skip-nx-cache.
This costs twice, because the execution is bound to the compile phase:
- the serial artifact build, and
- the 33m Frontend Unit Tests job, where
mvn test -pl :dotcms-core-webrunscompilefirst — so that job is dominated by a full workspace build beforenx affected -t testruns at all.
Backend
clean install at the root builds all 24 modules unconditionally, including ones the image cannot contain:
32.7s dotcms-integration then recompiled by all 7 IT shards anyway
22.9s dotcms-api-data-model CLI
17.6s dotcms-cli CLI
7.4s dotcms-postman
6.6s dotcms-ui-e2e
1.3s dotcms-test-karate
------
1.48m of the 7.0m reactor (21%)
The CLI is 40.5s of every build and is doubly redundant: the CLI Tests job runs verify -pl :dotcms-api-data-model,:dotcms-cli, which recompiles those sources itself — and CLI tests are already gated behind the cli_test filter, so most PRs never run them.
Scope
- Narrow the frontend build to the projects the WAR contains
- Trim the Maven reactor so the artifact build skips test-only and CLI modules
Out of scope
Remote caching (nx or WAR-level reuse across PRs) — tracked separately; it needs a storage decision.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Initial Artifact Build and the Frontend Unit Tests job, then inspect the core-web Maven compile and root clean install commands. Verify which projects the WAR webResources block requires and identify the test-only and CLI modules that can be excluded from the artifact reactor. Done means the artifact remains complete while CI avoids rebuilding discarded modules.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system, ci-cd, performance
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100