copyTemplates() treats chart/templates/ as an all-or-nothing override, silently dropping all SAP-generated templates

[xyunxylona]

Summary

If a project has any file under chart/templates/, the plugin's copyTemplates() early-returns and skips generating every SAP template (cap-operator-cros.yaml, domain.yaml, _helpers.tpl, plus the contents of commonTemplates/). The build succeeds with no warning. The resulting Helm chart contains only the user's file.

If that chart is then deployed by ArgoCD with auto-prune on, ArgoCD sees the SAP-generated resources as "removed from source" and deletes them from the cluster. Which is what happened to us.

What we hit

We added a single chart/templates/external-secret.yaml to wire up an ExternalSecret for a crypto key. After the next build, ArgoCD synced and started deleting ServiceBindings, CAPApplication, Domain, etc. - everything the plugin would normally generate. Our tenants all went down as a result.

Root cause

async copyTemplates() {
    if (exists(path.join(this.task.src, 'chart/templates'))) {
        return await this.copy(...).to(...)   // user files only
    }
    // SAP templates only generated when chart/templates/ does NOT exist
    await this.copy(commonTemplates).to(...)
    // ... domain.yaml, cap-operator-cros.yaml, _helpers.tpl
}

The conditional is a directory-existence check, not a per-file check. So chart/templates/external-secret.yaml is enough to make the plugin skip every other template it would otherwise produce.

Why this is hard to spot at build time

• The build doesn't fail or warn. It just produces a chart missing most of its templates.
• Adding files under chart/templates/ is the natural Helm convention for "extra resources I want shipped with my chart." There's nothing in the plugin's README or schema that flags this directory as off-limits.
• The damage shows up at deploy time, not at build time, and only if the deployment tool prunes (ArgoCD, helm upgrade --atomic, etc.).

Suggested fix

A few options:

1. Merge instead of replace. Generate the SAP templates first, then copy any user files in chart/templates/ on top. Filename collisions could be a hard error or a warning.
2. Use a different directory for user-supplied templates (e.g. chart/extra-templates/ or chart/user-templates/) and always merge it into the generated output. Keeps chart/templates/ for plugin output only and removes the foot-gun.
3. At minimum, have the plugin's build step (i.e. throw from copyTemplates() during cds build) error out when chart/templates/ exists alongside a config that expects SAP templates. The error message should explain that SAP templates are being skipped and point at the supported way to add extra resources. Today the plugin produces a broken chart with no signal.

Option 2 is the cleanest because it removes the ambiguity entirely. Option 1 is a less disruptive change if backward compatibility is the priority.