🤖 Fix for issue #60: Feature Request: Environment-Specific Secrets in Parent Stacks

.sc/secrets.v2.example.yaml

@@ -0,0 +1,76 @@
+# Environment-Specific Secrets Configuration Example
+# Schema Version: 2.0
+#
+# This example demonstrates how to configure environment-specific secrets
+# while maintaining backward compatibility with shared secrets.
+
+schemaVersion: "2.0"
+
+# Shared secrets are available to all environments (backward compatible)
+# These will be used as fallback when environment-specific values are not found
+values:
+  SHARED_API_KEY: "shared-api-key-value"
+  SHARED_CONFIG: "shared-config-value"
+
+# Environment-specific secrets override shared values for specific environments
+environments:
+  production:
+    values:
+      # Production-specific API key overrides the shared value
+      API_KEY: "production-api-key"
+      DATABASE_URL: "postgres://prod-db.example.com:5432/mydb"
+      REDIS_HOST: "redis-prod.example.com"
+
+  staging:
+    values:
+      # Staging-specific API key
+      API_KEY: "staging-api-key"
+      DATABASE_URL: "postgres://staging-db.example.com:5432/mydb"
+      REDIS_HOST: "redis-staging.example.com"
+
+  development:
+    values:
+      # Development uses local resources
+      API_KEY: "dev-api-key"
+      DATABASE_URL: "postgres://localhost:5432/mydb"
+      REDIS_HOST: "localhost"
+
+# Usage examples:
+#
+# 1. In stack configuration files, use placeholders:
+#    credentials: "${secret:API_KEY}"
+#
+# 2. The system will automatically resolve to the environment-specific value
+#    based on the deployment environment (production, staging, development)
+#
+# 3. If a secret is not found in the current environment, it falls back
+#    to the shared value (e.g., SHARED_API_KEY)
+#
+# 4. You can explicitly request a specific environment's value:
+#    credentials: "${secret:API_KEY:production}"
+#
+# 5. For parent/child stack configurations:
+#    - Child stacks inherit secrets from parent stacks
+#    - The child's environment is used to resolve parent secrets
+#    - This allows different environments to use different secrets from the same parent
+
+# Migration from v1.0 to v2.0:
+#
+# If you have an existing v1.0 configuration:
+# schemaVersion: "1.0"
+# values:
+#   API_KEY: "some-value"
+#
+# Simply update the schema version and add environment sections:
+# schemaVersion: "2.0"
+# values:
+#   API_KEY: "fallback-value"  # Now used as shared/fallback
+# environments:
+#   production:
+#     values:
+#       API_KEY: "production-value"
+#   staging:
+#     values:
+#       API_KEY: "staging-value"
+#
+# The v1.0 configuration will continue to work without any changes!