deploy-camunda CLI shouldn't need code changes when CI scenarios/fixtures/persistence change

[eamonnmoloney]

Summary

Adding or removing a CI scenario, persistence layer, fixture, or pre-install script — a change to YAML/data under charts/<version>/test/ — currently forces an accompanying change to the Go deploy-camunda CLI (and therefore a CLI rebuild/release). Data and code are coupled where they should be independent: a YAML change alone should never require shipping a new CLI binary.

This was hit repeatedly while working on #6339 (CNPG → companion swap): swapping a few scenarios in ci-test-config.yaml required editing Go source and Go tests.

Concrete coupling points

1. Hardcoded validPersistence list — scripts/camunda-core/pkg/scenarios/scenarios.go:80 enumerates every persistence name as a Go string slice. Adding values/persistence/<name>.yaml does nothing until this slice is edited. It already drifts: the slice has 14 entries (elasticsearch-external, elasticsearch-external-self-signed, opensearch-external, rdbms-oracle, …) while charts/camunda-platform-8.10/.../values/persistence/ has 10 files — the two are not derived from each other.

2. Hardcoded help text + shell completions — scripts/deploy-camunda/cmd/prepare_values.go and scripts/deploy-camunda/cmd/root.go repeat the persistence/identity name lists in flag help and completion functions (see also the "New Persistence Layer" checklist in AGENTS.md, which literally instructs editing three Go files to add one YAML file).

3. Go-test allowlists keyed by filename — scripts/deploy-camunda/matrix/lifecycle_hook_test.go (preSetupScriptAllowlist, commonResourcesAllowlist) must be hand-edited whenever a fixture/script under common/resources/ or pre-setup-scripts/ is added or removed, or TestLifecycleFixtures fails.

4. Tests that hardcode scenario names — e.g. matrix/config_test.go's TestGenerate_PropagatesPreInstall pinned the rdbms scenario; removing rdbms's pre-install hook broke the test and forced a code edit (it had to be retargeted to hub-external-db). matrix/matrix_test.go similarly references specific scenario names.

Why this is wrong

• The scenario registry / ci-test-config.yaml (and the values/** directories) are the source of truth for data. The CLI should discover valid persistence/identity/feature names and fixture references from the filesystem/config at runtime, not from a parallel hardcoded list that must be kept in sync by hand.
• Every drift between the two lists is a latent bug (an invalid name passes, or a valid one is rejected) and every data change carries an unnecessary code-review + release cost.
• It blocks the per-version scenario-registry epic's goal (Reduce CI scenario merge conflicts with a composable scenario registry #6264 / chore(8.10): migrate ci-test-config integration block to composable scenario registry #6318) of "adding a scenario = one YAML file."

Proposed direction (not prescriptive)

• Derive validPersistence (and identity/feature/platform name validation) by listing values/persistence/*.yaml etc. for the target version, instead of the hardcoded slice. Same for shell completions (dynamic completion from the filesystem).
• Replace the filename allowlists in lifecycle_hook_test.go with a convention (e.g. a small per-directory .meta/manifest, or a documented naming rule) so unreferenced-but-intentional files don't require editing Go.
• Make scenario-targeted tests data-driven (assert a property over all scenarios, or look up "any scenario with a pre-install hook") rather than pinning a named scenario.
• Acceptance: adding/removing a scenario, persistence layer, fixture, or script is a pure YAML/file change — no edits to scripts/**.go and no CLI release required; CI catches drift by construction.

Context

Surfaced during #6339 (workaround for the CNPG CI flakiness #6338).

[distro-ci]

🧭 Triage Assessment

Field	Value
Work type	TASK
Kind	refactor
Severity	🔴 High
Likelihood	🔥 High
Confidence	0.86

📝 Rationale

Issue #6340 is in scope for the SM Platform Distribution team because the team-boundaries document explicitly assigns Helm Charts, the camunda/camunda-platform-helm repository, and automated scenario testing/deployments to Distribution. I classify it as TASK rather than BUG because the Distro bug guide reserves bug for incorrect existing behavior or broken functionality, while the non-feature triage path covers maintenance, cleanup, refactoring, and tech debt; this issue is framed as removing code/data coupling, replacing hardcoded allowlists with discovery/convention, and making tests data-driven so scenario/persistence/file changes stop forcing Go edits and CLI releases. kind=refactor fits best because the requested outcome is restructuring the deploy-camunda and matrix-validation implementation around the existing filesystem/config source of truth, with no new customer-facing feature requested and no docs-only scope. Severity=high and likelihood=high are the best task-style proxies here: the impact is cross-component and delivery-affecting (CLI validation/help/completions, lifecycle-hook tests, scenario registry behavior, and release overhead), and the issue states the problem was hit repeatedly during #6339; related repo work also shows repeated Go/tooling edits just to keep persistence/help/completion lists aligned with YAML-driven scenario changes. The closest same-repo similar tracker is #6264, which already defines the broader scenario-registry initiative and explicitly aims for adding a scenario to become a small data-only change while preserving deploy-camunda behavior; #6298 is the first concrete migration step for 8.10, so this issue looks overlapping/adjacent rather than a strict duplicate of a resolved item. The issue has enough information for triage because it clearly describes the limitation, affected area, concrete coupling points, why the current state is problematic, and the desired acceptance criteria.

🔍 Similar Issues

#6264, #6298

---

🤖 This issue was automatically triaged by an AI-based system.
✋ If you believe this assessment is incorrect, update the labels or add the triage:manual label for human review.

[Ian-wang-liyang]

Partial overlap callout: cleanup PR #6355 (closes #6302) deletes scripts/deploy-camunda/matrix/lifecycle_hook_test.go outright, which removes the test-side hand-editing pressure on preSetupScriptAllowlist / commonResourcesAllowlist (this issue's point 3). The orphan-walk invariants those tests enforced were already migrated into RegistryValidator.Validate by #6318, so coverage is broader, not narrower.

Still outstanding for point 3: the allowlist constants in scripts/deploy-camunda/matrix/lifecycle_allowlist.go remain — they're consumed by RegistryValidator to exempt helper files from the orphan walk. Adding/removing a helper script under pre-setup-scripts/ or fixture under common/resources/ still requires hand-editing those constants. That's the real work for #6340 point 3 (replace constants with a filesystem convention — per-dir .meta or naming rule — so the validator discovers allowlist entries automatically).

Once point 3 lands, the entire allowlist subsystem collapses to zero code. The cross-version dead-entry walk that #6355 drops (per #6302 Q1) had no future after point 3 anyway — there are no allowlist entries to check the deadness of when the concept itself goes away.

Sequencing-wise this is fine: #6302 ships first (mechanical cleanup, narrow scope), then #6340 ideally splits into 4 sub-issues for the 4 decoupling points.