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 1m 54s —— View job

---

Code Review

• Read PR diff (config.json + ContentTypeResourceTests.json)
• Verify collection still runs exactly once after the group move
• Analyze the create-if-missing setup request and its interaction with sibling ensure tests
• Check idempotency / replay safety

---

I reviewed both changed files. This is a config-only rebalance plus a self-containment fix for the moved collection. The reasoning in the PR body and the follow-up comment checks out against the code.

Verification

• Runs once: ContentTypeResourceTests is removed from category-content (line 11 old) and added to template (config.json:49). It appears in exactly one named group, and default is "everything not in a named group" (dotcms-postman/index.js), so no duplicate execution. ✅
• Setup is idempotent: The new "Ensure Video DotAsset type exists (setup)" request accepts [200, 201, 400], so a re-run (retry / already-exists) passes cleanly — 400 = already exists. Correct replay handling for a POST create. ✅
• Setup placement: It's the first item in the Test Get ContentTypes folder, ahead of the ensure assertions at :2650. The first Video reference in the collection is this setup request (line 1871), so nothing earlier depends on the type. ✅
• Sibling test not broken: "WITHOUT 'ensure' param: video NOT present" (:2464) fetches per_page=10 sorted name ASC and asserts Video is absent. Video sorts to the end alphabetically, so it stays off page 1 even now that the type exists — the assertion still holds. The adjacent "exactly 10 items" check (:2440) is likewise unaffected since a fresh boot has well over 10 system types. ✅
• Workflow GUID: d61a59e1-a49c-46f2-a929-db2b4bfa88b2 is the shared System Workflow id used across many postman/karate fixtures, so the create body is valid. ✅

New Issues

None blocking.

• 🟡 Medium (nit): ContentTypeResourceTests.json:7 — the diff adds a stray blank line with trailing tabs inside the info block (after _exporter_id). Harmless to the JSON, but it's an unintended whitespace edit; worth dropping to keep the diff to just the meaningful setup request.

The only real behavioral risk — an ordering dependency now that the collection runs in a different group — is exactly what green CI on this PR confirms. The root-cause + fix in 88d993b6 addresses the one dependency that surfaced (the Video type). Approach is sound.
· 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