perf(test): run full-reindex IT tests first in each suite

[wezell]

Proposed Changes

Fixes #36910

Integration tests accumulate content and never clean up (cleaning up is time consuming as well). MainBaseSuite runs @SuiteClasses in declaration order with no shuffling, so a test that does a full reindex or edits base content types pay for all the content added previous tests. For example, ESMappingUtilHelperTest runs a reindex and has to reindex the entire accumulated content from every test rather than its own content.

This moves those classes to the front of each suite. Same classes, same suites, different declaration order — no behavioral change.

Suite	Test class	Old position	New	Measured cost
1a	Task240306MigrateLegacyLanguageVariablesTest	55/76	1	419.2s
1a	TemplateAPITest	67/76	2	117.9s
1a	ContainerAPIImplTest	68/76	3	68.6s
1b	HostAPITest	76/83	1	115.4s
1b	ESContentFactoryImplTest	80/83	2	159.3s
2a	MultiTreeAPITest	45/51	1	100.2s
2b	ESMappingUtilHelperTest	285/297	1	—
2b	ReindexThreadTest	232/297	2	0.001s
2b	ContentletIndexAPIImplMappingTimeoutIT	233/297	3	—
2b	ReindexAPITest	234/297	4	65.9s
2b	CleanUpFieldReferencesJobTest	220/297	5	5.3s
2b	EMAWebInterceptorTest	288/297	6	—

Classes were picked from CI per-class timings crossed with verified scan patterns (findAll*, findAllVersions*, executeUpgrade, fullReindexStart, refreshAllContent, createContentIndex) — not a loose grep on "reindex". Each moved block carries a comment explaining the ordering constraint so new full-scan tests are added to the front.

Two of the 2b moves are cheap in isolation (ReindexThreadTest at 0.001s, CleanUpFieldReferencesJobTest at 5.3s) — they are kept in the block because they are genuinely reindex-touching and cost nothing at the front, but the real 2b wins are ESMappingUtilHelperTest and ReindexAPITest.

Checklist

• Tests: no new tests — this is a pure reordering of existing suite declarations
• ./mvnw test-compile -pl :dotcms-integration passes with 0 errors
• Each suite's set of @SuiteClasses entries verified identical to main by fully-qualified name — nothing added, removed, or duplicated
• CI wall-clock compared against the pre-change baseline (that is what this draft is for)

Additional Info

Not addressed here:

• The PublishingResourceIntegrationTest hang (one 2b run cancelled at the 2h job timeout, another idle 26m at position 275/297). That is bundle teardown, not reindex — reordering does not fix it.
• Splitting MainSuite2b (297 classes, 3.6x the next largest suite).
• The ~6m25s gap between the last IT job finishing and Test Report firing.

🤖 Generated with Claude Code

This PR fixes: #36910

[claude]

Claude finished @wezell's task in 2m 17s —— View job

---

Code Review: reorder IT suites to run reindex/full-scan tests first

Verified against ce9fd437 (pre-PR commit on this branch):

• Class sets identical in all three suites — for each of MainSuite1a, MainSuite2a, MainSuite2b the sorted set of .class entries matches the pre-change version exactly (nothing added, removed).
• No duplicates introduced in any suite.
• 2b balances precisely: 6 classes hoisted into the new front block, the same 6 removed from their old positions.

This is a pure declaration-order change, as claimed.

New Issues

No code-correctness issues. One risk worth calling out explicitly, given it already bit this PR:

• 🟡 Medium: MainSuite2b.java:258 (and the 1a/2a front blocks) — Reordering @SuiteClasses is not guaranteed to be behavior-neutral. MainBaseSuite runs classes in declaration order with no per-class cleanup, so any implicit inter-class ordering dependency (test A leaves state that test B relies on, or B assumes A ran first) will surface as a pass→fail flip. This exact hazard already materialized on this branch: commit 9ac507fe reverted the MainSuite1b reordering because it "exposes an order dependency." The 1a/2a/2b moves haven't hit one yet, but the "no behavioral change" framing is only true if no such dependency exists among the moved classes — which only a green CI run proves. The PR checklist correctly leaves "CI wall-clock vs baseline" unchecked; that same CI run is also the sole guard against a latent order dependency. What to verify: full green run of 1a, 2a, 2b (not just compile) before merge. If any moved class (ESMappingUtilHelperTest, ReindexAPITest, ContainerAPIImplTest, etc.) fails only after the move, that's a pre-existing order coupling the move exposed — same class of issue as the 1b revert.

The per-block comments explaining the ordering constraint are a good touch and will help keep new full-scan tests at the front.

· issue-36910-reorder-it-suites

[wezell]

First CI run results (run 31058941959):

Suite	Result	Notes
MainSuite 2b	✅ 35m56s	No hang; ~2 min under the 38m median, well under the 53m+ hang pattern
MainSuite 2a	✅ 19m47s
MainSuite 3a	✅ 34m27s
Junit5 / OpenSearch Upgrade	✅
MainSuite 1b	❌ 42m	Order dependency exposed — see below
MainSuite 1a	🚫 cancelled	fail-fast collateral from 1b, no signal

1b failure: moving HostAPITest and ESContentFactoryImplTest to the front deterministically breaks HTMLPageAssetRenderedTest (shouldReturnPageHTMLForPersona, shouldReturnParserContainerUUID — failed on all 4 retry runs, plus 24 flakes across the class). HostAPITest.makeDefault() switches the system-wide default host (and back) and its delete paths fire async host-delete jobs; with the old ordering it ran at 92% so almost nothing observed that state. This is a pre-existing test-isolation bug, not a regression in the moved tests.

Pushed 9ac507fe65 reverting only the 1b block to main's order — 1a/2a/2b reorderings stay. If someone later fixes the isolation issue (restore default host in an @AfterClass, or make HTMLPageAssetRenderedTest resolve its own site instead of relying on ambient state), 1b can be reordered again for the remaining ~1-2 min.