Update Chart to 0.68.2 and enhance SQL secret management.

[liorcic-huskeys]

What was changed

Added flexible secretRef configuration for SQL persistence connections that allows storing any combination of connection parameters (host, port, database, user, password) in Kubernetes secrets with automatic fallback to values.yaml for unspecified parameters.

Key changes:

• Added new sql.secretRef configuration with optional keys: hostKey, portKey, databaseKey, userKey, passwordKey
• Each parameter can independently be sourced from a secret or values.yaml
• Added validation requiring at least one key when secretRef.name is specified
• Marked existingSecret and secretName as deprecated (maintained for backward compatibility)
• Updated templates: _helpers.tpl, server-deployment.yaml, server-configmap.yaml, _admintools-env.yaml

Why?

Currently, when using external Postgres databases, only the password can be stored in a secret (via existingSecret or secretName). All other connection parameters (host, port, database, user) must be hardcoded in values.yaml, which creates several problems:

1. Security: Connection details are exposed in Git repositories
2. Secrets Management: External secret operators (like External Secrets Operator, CloudNativePG) cannot fully manage database connections
3. Multi-environment deployments: Difficult to use the same chart across environments with different database endpoints
4. Operator integration: Database operators that generate complete connection secrets require workarounds

This change allows users to store all connection parameters in secrets while maintaining full backward compatibility with existing configurations.

Checklist

1. Closes [Feature Request] Add support for deploying and using PostgreSQL #637

2. How was this tested:

   Test Scenario 1: Only password in secret

   sql:
     driver: "postgres12"
     host: "my-postgres"
     port: 5432
     database: "temporal"
     user: "temporal"
     secretRef:
       name: my-secret
       passwordKey: password

   • Created secret with only password
   • Verified ConfigMap uses values.yaml for host/port/database/user
   • Verified password comes from secret
   • Confirmed pods start successfully and connect to database

   Test Scenario 2: All parameters from secret

   sql:
     driver: "postgres12"
     secretRef:
       name: postgres-connection
       hostKey: host
       portKey: port
       databaseKey: database
       userKey: username
       passwordKey: password

   • Created secret with all connection parameters
   • Verified ConfigMap uses environment variables for all fields
   • Verified admin-tools job completes successfully with correct SQL_* env vars
   • Confirmed schema setup and server pods connect properly

   Test Scenario 3: Mixed configuration

   sql:
     driver: "postgres12"
     host: "localhost"
     port: 5432
     database: "temporal"
     secretRef:
       name: db-creds
       userKey: username
       passwordKey: password

   • Verified host/port/database from values.yaml
   • Verified user/password from secret
   • Confirmed correct ConfigMap generation

   Test Scenario 4: Backward compatibility

   • Tested existing existingSecret configuration still works
   • Tested existing secretName configuration still works
   • Verified no breaking changes to existing deployments

   Test Scenario 5: Validation

   • Confirmed error when secretRef.name is set without any keys
   • Verified helpful error message guides users to specify at least one key

   Test Scenario 6: Both stores (default and visibility)

   • Tested secretRef on both default and visibility stores simultaneously
   • Verified independent configuration works correctly
   • Confirmed admin-tools handles both stores with different secret configurations

3. Any docs updates needed?

   Yes - values.yaml has been updated with comprehensive inline documentation:

   • Added deprecation warnings for existingSecret and secretName
   • Added detailed comments explaining secretRef structure
   • Included example configuration showing all optional keys
   • Documented fallback behavior when keys are not specified

   Additional documentation updates recommended for docs.temporal.io:

   • Add section to "External PostgreSQL" configuration guide showing secretRef examples
   • Update best practices for secrets management with Temporal
   • Add migration guide from existingSecret/secretName to secretRef
   • Document integration patterns with External Secrets Operator and CloudNativePG

---

Example Configuration (for documentation):

server:
  config:
    persistence:
      default:
        driver: "sql"
        sql:
          driver: "postgres12"
          secretRef:
            name: temporal-postgres-secret
            hostKey: host
            portKey: port
            databaseKey: database
            userKey: username
            passwordKey: password
          maxConns: 20
          maxIdleConns: 20
          maxConnLifetime: "1h"

Where the secret is created by your database operator or secrets manager:

kubectl create secret generic temporal-postgres-secret \
  --from-literal=host='postgres.example.com' \
  --from-literal=port='5432' \
  --from-literal=database='temporal' \
  --from-literal=username='temporal_user' \
  --from-literal=password='secure_password'

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}