perf(test): move ContentTypeResourceTests to template postman group (#36914)

[wezell]

Proposed Changes

Config-only rebalance of Postman collection groups (dotcms-postman/config.json): move ContentTypeResourceTests from category-content to template.

Measured on run 31054926456: Category Content ≈ 40 min, of which ContentTypeResourceTests alone is 14m37s; the Template job is ~10 min (mostly the ~12 min shared boot overhead every Postman job pays). After the move both jobs land ≈ 25 min, cutting ~15 min off the Postman critical path with no new job and no extra dotCMS boot.

The default group is computed as "all collections not in any named group" (dotcms-postman/index.js), so the collection still runs exactly once. Each Postman job boots its own dotCMS, so the only behavioral risk is an undiscovered ordering dependency of ContentTypeResourceTests on the two collections that previously ran before it in its old group — CI on this PR answers that.

Related: #36910 / #36911 / #36913 (test speed initiative).

Checklist

• Tests (config-only; existing collections unchanged)
• Translations
• Security Implications Contemplated (none)

🤖 Generated with Claude Code

This PR fixes: #36914

[claude]

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

---

Code Review: Postman group rebalance

• Read the diff (config.json, ContentTypeResourceTests.json)
• Verify group-move correctness against index.js
• Check the new setup request for correctness / idempotency
• Assess ordering-dependency risk

Findings

No blocking issues. The change does what the description claims, and the reasoning holds up against the code.

What I verified:

1. Runs exactly once. dotcms-postman/index.js:290-302 computes default as every .json not listed in any named group. Moving ContentTypeResourceTests from category-content to template keeps it in a named group, so it neither gets dropped nor picked up by default. No double-run, no missed-run. ✅

2. Ordering dependency is addressed. The real risk of the move is that ContentTypeResourceTests previously relied on sibling collections (Category / ContentResourceV1) to indirectly create the Video type. The new Ensure Video DotAsset type exists (setup) item (ContentTypeResourceTests.json:1870) makes the collection self-contained by creating it up front. It's the first item in the Test Get ContentTypes folder, so it runs before the ensure-param assertions at lines 2418 and 2649. ✅

3. Idempotent / replay-safe. The setup test accepts [200, 201, 400] (:1880), so a re-run where Video already exists (400) passes. Given bail: true in the runner (index.js:181), an unexpected status would abort the collection — that's the intended fail-fast behavior, not a defect. ✅

4. Doesn't break the "without ensure" assertion. The Get ContentTypes without sending ensure param test (:2463) asserts Video is not in the first 10 results (name ASC, per_page=10). Video sorts near the end alphabetically, so creating it doesn't pull it into that page — and this was already the effective state before the move (Video was being created by sibling collections). Behavior is unchanged. ✅

5. Conventions. Hardcoded workflow id d61a59e1-... and the DotAsset clazz match existing usages elsewhere in this same collection, so they're consistent with the file. JSON structure of the inserted block is well-formed.

Minor (non-blocking)

• 🟡 The setup creates Video but nothing deletes it. That's intentional here (later tests depend on it existing, and creation is idempotent), so no action needed — just noting it's a persistent side effect within the collection's own dotCMS boot.

Only real residual risk is the one the author already called out: an unmeasured runtime split. CI on this PR is the authority on both the timing win and the ordering assumption.
· branch issue-36914-postman-rebalance

[wezell]

First run failed — root-caused and fixed in 88d993b6ea.

The Template job failed first (everything else was fail-fast cancellation): ContentTypeResourceTests' "Get ContentTypes sending ensure param" asserts a Video content type exists, and in the new group it doesn't. Forensics:

• The ensure param only forces requested types into the result page (ContentTypesPaginator → searchMultipleTypes) — it does not create them.
• Nothing in dotCMS creates a Video content type eagerly at startup (dotAsset was present in the failing run; Video was not).
• In the old category-content group the type existed by the time this collection ran — created indirectly by whatever ran before it. The collection was never self-contained; the group move just exposed it.

Fix: added a create-if-missing setup request (POST /api/v1/contenttype, accepts 200/201/400) at the top of the Test Get ContentTypes folder, so the collection passes regardless of group placement. The sibling "WITHOUT ensure param: video NOT present" test is unaffected — Video sorts past page 1 either way.

CI re-running now.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request