belt 0.4.0 → 0.4.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 5a04110a957fa2d24cbca0245df1aa6aa421547ac140467cb5e6a15e9d0e1fb1
-  data.tar.gz: 17ffdd470fe0dd613ac82cd0554c12146fb527ee1a6ccd179f3de4b3e3024eab
+  metadata.gz: e17e0755e497e26d8bd10604e6f050b0c6e0b69e3627276f8d83be984862d5da
+  data.tar.gz: b4249c4ac11715ae45a091c3eced0d0bad8ecd5d89a750edfaa8586ab6449758
 SHA512:
-  metadata.gz: 540c4da110ef61d412c09af5ce4db33bd534ec460d636ac2988e9784cb0fc58ac54e6cd9eeb201b48f863832d7d936ae5677bbcb78d37e702f04915e234ee230
-  data.tar.gz: ecc50065fcff0b93904c89cbc8c0e3c1a0c45e8f54c7c12af80d9546d894ed12b0a9f8103f8ca5eae3623c1cbd0e38d703137acf86e242ca9fe05946734ac28f
+  metadata.gz: abe5b18f7eeeb92bba2863746e7cc71d854078462274993403c4d7b93af81ff2c82a3b5c1db2fbdf537f8a139ec15964d76aad042505ade12ad64e6069f40a5a
+  data.tar.gz: dba1d0cca64620fc48b495ee844600e7a8e38c577ad3f27ada191263038f38a081a3d640f9a66e00fd97c138e1686ae91654d6995225d357bec8a5016e903f5e

data/CHANGELOG.md

@@ -1,5 +1,70 @@
 # Changelog
 
+## Unreleased
+
+### Bug Fix
+
+- **`belt setup tables` no longer silently clobbers hand-added tables/GSIs.**
+  Regenerating `dynamodb.tf` is a full overwrite from `lambda/models/*.rb`, so a
+  table or `global_secondary_index` added straight into the `.tf` file — one the
+  models don't declare — used to vanish on the next run. Dropping a live GSI is
+  not harmless: queries against it start failing. The generator now diffs the
+  existing file and, when the regen would remove infrastructure it can't
+  re-derive, it warns and lists exactly what would disappear. An interactive run
+  prompts before overwriting; a generator auto-sync refuses and leaves the file
+  untouched. Pass `--force` (`-f`/`--yes`/`-y`) to overwrite anyway. The
+  `dynamodb.tf` header comment now spells out this behavior too. (Fixes the
+  misleading "harmless diff" framing in the 0.4.0 notes below.)
+
+- **Apply environment AWS profile in `belt deploy frontend`, `belt frontend env`, `belt logs`, and `belt server`**:
+  Standalone frontend deployment (`belt deploy frontend <env>`), frontend env generation (`belt frontend env <env>`),
+  log viewing (`belt logs`), and the local dev server (`belt server`) now load `infrastructure/<env>/belt.rb`
+  and apply its configured `aws_profile` and environment variables. Previously, running `belt deploy frontend <env>`
+  directly would query Terraform outputs without the environment's AWS profile, causing a 403 against remote S3
+  state backends and aborting with `Error: Could not determine S3 bucket. Run belt apply <env> first.`
+
+## 0.4.1
+
+### Feature
+
+- **`belt dns doctor`**: New diagnostic command that checks DNS health across all
+  environments. Shows zone status, NS delegation, ACM certificate state, and
+  API Gateway custom domain configuration. Use `--env prod` to check a specific
+  environment only.
+
+  ```bash
+  belt dns doctor
+  belt dns doctor --env prod
+  ```
+
+- **`belt dns sync-validation`**: New command to sync ACM validation CNAMEs from
+  an environment's zone to the root zone. Needed for apex domains (e.g., prod →
+  `example.com`) where the root zone is authoritative for the apex domain.
+
+  ```bash
+  belt dns sync-validation prod
+  ```
+
+- **Auto-sync ACM validation for apex environments**: `belt deploy prod` now
+  automatically syncs ACM validation CNAMEs to the root zone when deploying
+  environments that use the apex domain. No manual intervention needed — the
+  "prod is special" logic is handled by Belt internally.
+
+  This fixes the issue where prod ACM certificates would timeout waiting for
+  validation because the validation CNAMEs were created in the prod zone, but
+  ACM validates against the authoritative zone (the root zone managed by
+  `infrastructure/dns`).
+
+### Bug Fix
+
+- **Fix misleading nested environment domain announcement**: `belt generate
+  environment <name> <parent>` printed `Domain will be:
+  api.<env>.<parent>.<domain>`, but the deployed infrastructure actually uses
+  the single-level `api-<env>.<parent>.<domain>` form (the `api-` prefix keeps
+  the host under the parent's `*.<parent>.<domain>` wildcard cert). The message
+  now matches the real deployed domain. Infrastructure was already correct —
+  only the CLI output was wrong.
+
 ## 0.4.0
 
 ### New Features

data/lib/belt/cli/deploy_command.rb

@@ -14,6 +14,7 @@ require_relative 'zip_artifact_builder'
 require_relative 'nested_environment'
 require_relative 'cognito_sharer'
 require_relative 'dynamo_copier'
+require_relative 'dns_command'
 require_relative 'apex_dns_sync'
 
 module Belt
@@ -177,6 +178,11 @@ module Belt
         # Sync apex DNS records to root zone (if this is a prod/apex environment)
         run_apex_dns_sync
 
+        # Sync ACM validation CNAMEs for apex domains (e.g., prod)
+        # This handles the case where prod uses the apex domain (example.com)
+        # and needs validation CNAMEs in the root zone, not the env's zone.
+        sync_acm_validation_if_apex
+
         puts "\n✅ Deployed #{@env} successfully!"
         print_outputs(env_dir)
 
@@ -299,6 +305,27 @@ module Belt
         end
       end
 
+      # ─── ACM Validation Sync ────────────────────────────────────────
+
+      # For apex environments (prod), ACM validation CNAMEs need to be in the
+      # root zone (managed by infrastructure/dns), not the environment's zone.
+      # This is because the registrar points to the root zone, which is
+      # authoritative for the apex domain.
+      def sync_acm_validation_if_apex
+        # Only sync if DNS infrastructure exists
+        return unless Dir.exist?(File.join(@infra_dir, '..', 'infrastructure', 'dns')) ||
+                      Dir.exist?('infrastructure/dns')
+
+        # Check if this is an apex environment
+        return unless apex_environment?
+
+        DnsCommand.sync_acm_validation_if_needed(@env)
+      end
+
+      def apex_environment?
+        %w[prod production].include?(@env)
+      end
+
       # ─── Backup Phase ───────────────────────────────────────────────
 
       def run_backups