feat: support pgdog.toml from an existing Secret (configSecret)

[mscrivo]

Motivation

We run pgdog against databases whose hosts and admin credentials live in AWS Secrets Manager, rendered into a complete pgdog.toml by External Secrets Operator. That file can't go through chart values — it would put credentials into the ConfigMap — and overlaying it on the chart's copy with a subPath volume mount fails at container start with not a directory: the mount target /etc/pgdog/pgdog.toml is a symlink inside the ConfigMap volume, and container runtimes refuse to bind a file over it (kubernetes/kubernetes#61545). As published, there's no working way to feed the chart a Secret-sourced pgdog.toml.

What this does

Adds a configSecret value mirroring the existing usersSecret pattern:

configSecret:
  name: my-pgdog-config # existing Secret in the same namespace
  key: pgdog.toml       # remapped to pgdog.toml if named differently

When configSecret.name is set:

• the config volume is sourced from that Secret instead of the chart's ConfigMap (custom key remapped to pgdog.toml, same as usersSecret)
• the chart's pgdog.toml ConfigMap is not rendered (same treatment usersSecret gives the users Secret)

All parameters optional; default rendering is unchanged.

Notes

• plugins[].config entries render into the chart ConfigMap, so they aren't mounted when configSecret.name is set. Documented in values.yaml and the README; a Secret-provided pgdog.toml controls its own plugin config paths, so plugin files can be mounted via extraVolumes.
• Test coverage added: test/values-existing-config-secret.yaml plus assertions in test/test.sh that the volume source swaps, the key is remapped, and the ConfigMap is suppressed. ./test/test.sh passes.

🤖 Generated with Claude Code

[levkk]

Let's remove this, claude keeps trying to add tests here, but this is not how we want this repo to be tested imo.

If you add a yaml into test directory, it will be automatically rendered and checked for validity (with helm).

[levkk]

LGTM!