devlift-cli 0.1.4__tar.gz → 0.1.5__tar.gz

{devlift_cli-0.1.4 → devlift_cli-0.1.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: devlift-cli
-Version: 0.1.4
+Version: 0.1.5
 Summary: DevLift command-line tool: create, change, review and deploy DevLift resources from the terminal.
 License: Proprietary
 Keywords: devlift,devops,deployment,infrastructure,cli

{devlift_cli-0.1.4 → devlift_cli-0.1.5}/devlift_cli/MANUAL.md

@@ -509,7 +509,7 @@ devlift eks create --name NAME --app APP --env ENV --region REGION --type api|wo
                    [--set key=value ...] [--public] [-y]
 devlift eks settings                  Every key --set accepts, and when each applies.
 devlift eks settings <service>        Only the keys that apply to it, with its current values.
-devlift eks show <service> --env ENV  The configuration as it stands, with pending values marked.
+devlift eks show <service> --env ENV  The configuration, with any pending draft over it; pending rows name the deployed value too.
 devlift eks diff <service> --env ENV  Preview the pending change: Field | Deployed | Requested.
 devlift eks diff <service> --deployed The live configuration versus the last deployment.
 devlift eks edit <service> --env ENV [--set key=value ...]
@@ -752,7 +752,15 @@ last deployed. That one ignores drafts entirely, so on a service whose
 change is still a draft it shows the live row and its defaults, not what the
 draft proposes.
 
-`eks show` marks each value that a pending request would change.
+**`eks show` is not "what is deployed" while a request is open.** Its
+Configuration table is the live configuration with the open draft laid over
+it, so a pending row shows the value the draft *proposes*. Each such row is
+marked `pending (<status>) — deployed <value>`, so both numbers are visible.
+
+In `-o json` the same thing is spelled out: `settings` is the merged view,
+`deployed_settings` is what is actually running, and `pending` gives
+`{deployed, requested}` for each changed key. When `pending_request` is null
+there is no draft and `settings` is simply the deployed configuration.
 
 ### kong
 

{devlift_cli-0.1.4 → devlift_cli-0.1.5}/devlift_cli/__init__.py

@@ -1,3 +1,3 @@
 """DevLift command-line tool."""
 
-__version__ = "0.1.4"
+__version__ = "0.1.5"

{devlift_cli-0.1.4 → devlift_cli-0.1.5}/devlift_cli/commands/eks.py

@@ -110,13 +110,19 @@ def eks_show(
     region: str | None = typer.Option(None, "--region", help="Region, when the service runs in several."),
 ):
     """Show a service's configuration as it stands, marking values pending in an open request."""
-    from devlift_cli.ops.eks import LABELS, load_effective, _show
+    from devlift_cli.ops.eks import LABELS, load_effective, settings_from_config, _show
     from devlift_cli.render import output
 
     inv: Invocation = ctx.obj
     eff = load_effective(inv, Resolver(inv.api, inv.profile.name), service, env, region, for_edit=False)
     live = eff.live
     request = eff.draft
+    # `eff.settings` is the live config with the open draft laid OVER it, so for
+    # any pending key its value is what the draft proposes, not what is running.
+    # Reading it as "the current configuration" is the obvious mistake, and one
+    # that has been made, so the deployed values are published beside it rather
+    # than left to be inferred from pending_keys.
+    deployed_settings = settings_from_config(dict(live.get("config") or {}))
     data = {
         "service": eff.target.service_name, "service_config_code": eff.target.config_code,
         "environment": live.get("environment"), "region": eff.target.region_name,
@@ -129,8 +135,19 @@ def eks_show(
         "type": eff.service.get("service_type"), "repository": eff.config.get("repository"),
         "branches": eff.config.get("branches") or eff.config.get("selected_branches"),
         "language": f"{eff.language_label or ''} {eff.language_version or ''}".strip() or None,
-        "settings": eff.settings, "pending_request": {"code": request["code"], "status": request["status"]} if request else None,
+        # effective = deployed, with the pending draft laid over it.
+        "settings": eff.settings,
+        # what is actually running right now, whatever is pending.
+        "deployed_settings": deployed_settings,
+        "pending_request": {"code": request["code"], "status": request["status"]} if request else None,
         "pending_keys": sorted(eff.pending_keys),
+        # Both sides per changed setting, so "what is deployed" needs no
+        # cross-referencing of two dicts against a list of keys.
+        "pending": {
+            k: {"deployed": deployed_settings.get(k), "requested": eff.settings.get(k)}
+            for k in sorted(eff.settings)
+            if k in eff.pending_keys or (k in ("hpa_enabled", "min_replicas", "max_replicas") and "hpa" in eff.pending_keys)
+        } if request else {},
     }
 
     def table(d):
@@ -145,8 +162,15 @@ def eks_show(
         pend = set(d["pending_keys"])
         def mark(k):
             hit = k in pend or (k in ("hpa_enabled", "min_replicas", "max_replicas") and "hpa" in pend)
-            return f"pending ({d['pending_request']['status']})" if hit and d["pending_request"] else ""
-        return rows_table(["Setting", "Value", ""], [(LABELS.get(k, k), _show(v), mark(k)) for k, v in d["settings"].items()], title="Configuration")
+            if not (hit and d["pending_request"]):
+                return ""
+            # Name the value that is actually running. Marking the row "pending"
+            # while showing only the draft's number tells the reader the setting
+            # is changing but not what it is changing FROM, which is the half
+            # they need to judge it.
+            return f"pending ({d['pending_request']['status']}) — deployed {_show(d['deployed_settings'].get(k))}"
+        header = "Value (deployed)" if not d["pending_request"] else "Value (with pending draft)"
+        return rows_table(["Setting", header, ""], [(LABELS.get(k, k), _show(v), mark(k)) for k, v in d["settings"].items()], title="Configuration")
     inv.emit(data, table)
 
 

{devlift_cli-0.1.4 → devlift_cli-0.1.5}/devlift_cli/skill/SKILL.md

@@ -239,6 +239,16 @@ the approved rows. The summary is printed on every dry run, in json mode too.
   finished, and `eks status <service> --env <env>` also asks ArgoCD whether the
   pod is actually serving, which is the real "is it up" question. A finished
   pipeline is not a running application.
+- **`eks show` is not "what is deployed" when a request is open.** Its
+  `settings` are the live configuration with the open draft laid OVER it, so
+  for any pending key the value shown is what the draft PROPOSES. Quoting one
+  as the running value is wrong and has misled a user.
+  Check `pending_request` first. If it is null, `settings` is the deployed
+  configuration and you can quote it freely. If it is set, use
+  `deployed_settings` for what is running, or `pending` which gives
+  `{deployed, requested}` per changed key, or run `devlift eks diff <service>
+  --env <env>`. Never describe a value as current, running or deployed on the
+  strength of `settings` alone while something is pending.
 - **Never compare a cluster code with a cluster name.** `eks show` returns both
   `cluster` (the name, e.g. `acme-core-stage-mumbai-01-application-cluster`)
   and `cluster_code` (e.g. `infra-acme-eks-staging-mumbai-app-01`). They are

{devlift_cli-0.1.4 → devlift_cli-0.1.5}/devlift_cli/skill/reference/commands.md

@@ -63,7 +63,7 @@ devlift eks create --name NAME --app APP --env ENV --region REGION --type api|wo
                    --repository owner/name --branch main [--branch ...]
                    --language Go|Python|Node.js|"Java Maven"|"Java Gradle" --version 1.24
                    [--set key=value ...] [--public] [-y]
-devlift eks show <service> --env ENV            configuration as it stands; pending values marked
+devlift eks show <service> --env ENV            live config WITH any open draft over it; deployed_settings + pending{} give the real deployed values
 devlift eks diff <service> --env ENV            preview the pending request: Field | Deployed | Requested
 devlift eks diff <service> --deployed           instead: live config vs the last deployment
 devlift eks settings <service> --env ENV        the --set keys that apply to it, with current values

{devlift_cli-0.1.4 → devlift_cli-0.1.5}/devlift_cli/skill/reference/workflows.md

@@ -59,7 +59,9 @@ the user it is a draft, nothing is deployed, and continue with workflow 6.
 ## 4. Change a running service's settings
 
 ```
-devlift eks show orders --env stage --no-input -o json           # current values; pending_request + pending_keys if a draft exists
+devlift eks show orders --env stage --no-input -o json           # settings = live WITH the open draft over it.
+#   pending_request null  -> settings IS the deployed config
+#   pending_request set   -> use deployed_settings, or pending{key:{deployed,requested}}, or `eks diff`
 devlift eks edit orders --env stage --set memory_limit=1 --no-input     # Current | New, exit 5
 devlift eks edit orders --env stage --set memory_limit=1 --no-input -y -o json
 # → {changed, changes{field:{from,to}}, queue_code, queue_status}

{devlift_cli-0.1.4 → devlift_cli-0.1.5}/devlift_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: devlift-cli
-Version: 0.1.4
+Version: 0.1.5
 Summary: DevLift command-line tool: create, change, review and deploy DevLift resources from the terminal.
 License: Proprietary
 Keywords: devlift,devops,deployment,infrastructure,cli