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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: devlift-cli
-Version: 0.1.2
+Version: 0.1.4
 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.2 → devlift_cli-0.1.4}/devlift_cli/MANUAL.md

@@ -227,11 +227,13 @@ devlift clusters list [--app NAME] [--env ENV] [--region REGION] [--type eks|ecs
 ```
 
 The clusters services run on, and the `--cluster` values for `eks create`.
-Narrowed to placements you could really create in: the backend reports only
-the environments this deployment serves, and the placement allowlist
-(section 5) says which of those offer EKS or ECS. Clusters outside both are
-real but unusable from here, so they are hidden and counted; `--all` shows
-everything the backend reports.
+Narrowed by three filters, the same ones a create goes through: the backend
+reports only the environments this deployment serves, the placement allowlist
+(section 5) says which of those offer EKS or ECS, and only a **registered**
+cluster may take a new service. Anything outside those is real but can never
+be chosen, so it is hidden and counted. `--all` drops all three and shows
+everything the backend reports, for checking what exists rather than for
+choosing.
 
 ```
 devlift clusters list --type eks --app core --env stage
@@ -239,16 +241,20 @@ devlift clusters list --type eks --app core --env stage
 
 ```
 22 of 25 hidden: not a placement this deployment offers; --all shows everything.
+2 more hidden: not registered, so no service can be created on them.
 
-Cluster                                         Type  Environment  Region  Application  Registered
+Cluster                                        Type  Environment  Region  Application  Registered
 acme-core-stage-mumbai-01-application-cluster  EKS   stage        Mumbai  core         yes
-…two more in the same placement, not registered
 ```
 
-Within that, **Registered** is the flag that matters: only a registered
-cluster may take a new service, and `eks create` will not offer the others.
-A row whose Application reads "tenant-level" belongs to no single product
-and is the fallback for products with no cluster of their own.
+Everything listed is a cluster `eks create` would accept. A row whose
+Application reads "tenant-level" belongs to no single product and is the
+fallback for products with no cluster of their own.
+
+**Name and code are two labels for one cluster.** The Cluster column and
+`eks create` both show the name; the Code column and `eks show`'s
+`cluster_code` show the backend's identifier. They look nothing alike, so do
+not read a difference between them as two different clusters.
 
 With exactly one registered cluster in a placement, `eks create` fills it in
 silently. With several it asks, or wants `--cluster` under `--no-input`.

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

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

{devlift_cli-0.1.2 → devlift_cli-0.1.4}/devlift_cli/commands/clusters.py

@@ -66,14 +66,17 @@ def clusters_list(
 ):
     """List the clusters a service can run on.
 
-    Narrowed to placements this deployment serves and the placement allowlist
-    permits, so a cluster listed here is one a service could actually be
-    created on. `--all` shows everything the backend reports.
-
-    "Registered" is the flag that matters within that: only a registered
-    cluster may take a new service, and `eks create` will not offer the
-    others. A cluster with no application is tenant-level and is the fallback
-    for every product that has none of its own.
+    Three filters, the same ones every create goes through: placements this
+    deployment serves, placements the allowlist permits, and registration.
+    Only a registered cluster may take a new service, so an unregistered one
+    is never a candidate and is not listed. Everything shown here is a cluster
+    `eks create` would actually accept.
+
+    `--all` drops all three and shows everything the backend reports, which is
+    for checking what exists rather than for choosing.
+
+    A cluster with no application is tenant-level and is the fallback for
+    every product that has none of its own.
     """
     inv: Invocation = ctx.obj
     res = Resolver(inv.api, inv.profile.name)
@@ -95,8 +98,20 @@ def clusters_list(
     if not show_all:
         before = len(rows)
         rows = _placeable(res, rows)
-        if before > len(rows):
-            output.info(f"{before - len(rows)} of {before} hidden: not a placement this deployment offers; --all shows everything.")
+        placement_hidden = before - len(rows)
+
+        # Unregistered clusters are not offerable, so listing them is worse than
+        # useless: a service cannot be created on one, and naming it invites a
+        # comparison against the registered cluster that reads as a discrepancy.
+        # `--all` still shows them, for someone checking what exists.
+        registered = [r for r in rows if r.get("is_registered")]
+        unregistered_hidden = len(rows) - len(registered)
+        rows = registered
+
+        if placement_hidden:
+            output.info(f"{placement_hidden} of {before} hidden: not a placement this deployment offers; --all shows everything.")
+        if unregistered_hidden:
+            output.info(f"{unregistered_hidden} more hidden: not registered, so no service can be created on them.")
     inv.emit(rows, lambda d: rows_table(
         ["Cluster", "Type", "Environment", "Region", "Application", "Registered", "Status", "Code"],
         [(r.get("cluster_name") or r.get("name"), r.get("cluster_type"), r.get("environment"),

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

@@ -119,7 +119,13 @@ def eks_show(
     request = eff.draft
     data = {
         "service": eff.target.service_name, "service_config_code": eff.target.config_code,
-        "environment": live.get("environment"), "region": eff.target.region_name, "cluster": live.get("infrastructure_mst_code"),
+        "environment": live.get("environment"), "region": eff.target.region_name,
+        # The NAME, the same identifier `eks create` and `clusters list` print.
+        # This used to report infrastructure_mst_code, so the two commands named
+        # one cluster two different ways and anyone comparing them concluded the
+        # service had moved. The code is still here, under its own key.
+        "cluster": eff.config.get("cluster_name") or live.get("infrastructure_mst_code"),
+        "cluster_code": live.get("infrastructure_mst_code"),
         "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,
@@ -131,6 +137,8 @@ def eks_show(
         output.err_console.print(kv_table([
             ("Service", d["service"]), ("Type", d["type"]), ("Environment", f"{d['environment']} / {d['region']}"),
             ("Cluster", d["cluster"]), ("Repository", d["repository"] or "–"),
+            # Kept out of the table: the code adds nothing a reader can act on,
+            # and showing both invites exactly the comparison this fixes.
             ("Branches", ", ".join(d["branches"] or []) or "–"), ("Language", d["language"] or "–"),
             ("Pending request", f"{d['pending_request']['code']} ({d['pending_request']['status']})" if d["pending_request"] else "none"),
         ], title=d["service"]))

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

@@ -160,19 +160,29 @@ are in `reference/workflows.md`.
    and prints two tables on stderr: the service (placement, cluster it
    picked, repository, branches, language) and the Configuration table with
    a "From" column saying which values came from the language template.
-3. **Show the user those template values as they were printed and ask:**
-   "These are the standard <language> values. Apply them, or tell me what to
-   change?" That reply is text and ends the turn — no dialog, no tool call,
-   because a dialog would hide the table they are deciding on. Do not rerun
-   with `-y` until they answer.
+3. **Reproduce both tables in your reply, then ask.** Paste them as the
+   command printed them, inside a code block, every row, in the same order,
+   with the "From" column intact. They are the summary. Do not replace them
+   with prose, do not show only the rows you think matter, and do not lead
+   with your own commentary: the user is about to approve these exact values
+   and cannot approve what they cannot see. Anything you want to point out
+   goes AFTER the tables, in a line or two.
+
+   Then ask: "These are the standard <language> values. Apply them, or tell
+   me what to change?" That reply is text and ends the turn — no dialog, no
+   tool call, because a dialog would hide the table they are deciding on. Do
+   not rerun with `-y` until they answer.
 4. A change ("port 9000", "1 GiB memory limit", "turn on autoscaling 2 to 4")
    becomes `--set` flags on the rerun: `--set port=9000`,
    `--set memory_limit=1`, `--set hpa_enabled=true --set min_replicas=2
    --set max_replicas=4`. Rerun without `-y` once more only if the change is
-   large; otherwise rerun with `-y` and report the service, configuration and
-   queue codes.
-5. Say it is a **draft** and name the next step: `request submit`, then a
-   reviewer's `approval approve`, then `eks deploy`.
+   large; otherwise rerun with `-y`.
+5. **Report what is now waiting to be reviewed, not the codes it returned.**
+   Run `devlift request show <service> --env <env> --no-input -o json` and
+   show what it lists: every row in the change set and the fields each one
+   changes. Say it is a **draft**, nothing is deployed, and name the next
+   step: `request submit`, then a reviewer's `approval approve`, then
+   `eks deploy`.
 
 The same show-then-ask shape applies to every write: `eks edit` and the
 update commands print Current | New, `kong route …` prints the route change,
@@ -181,12 +191,65 @@ the approved rows. The summary is printed on every dry run, in json mode too.
 
 ## Reporting back to the user
 
-- After a dry run (exit 5) show the summary the command printed and ask for
-  the go-ahead. After a write, report the codes it returned: resource code and
-  workflow id for resources; queue code and status for drafts and review
-  verbs; workflow id for a deploy.
+- **After a dry run (exit 5), paste what the command printed, verbatim, in a
+  code block**, then ask for the go-ahead. Every row of every table, in order.
+  A summary you wrote yourself is not a substitute: the user is approving the
+  values in that output, so replacing it with "two differences worth your
+  call" hides the other twenty they are also agreeing to. Commentary is
+  welcome after it, never instead of it.
+- **After a draft write, show what will go to review — not the codes.**
+  `eks create`, `eks edit` and `kong route …` all save a draft. The service
+  code, the configuration code and the queue code are plumbing: they belong in
+  your next tool call, not in a sentence a person reads. Run
+  `devlift request show <service> --env <env> --no-input -o json` and report
+  what it lists: every row in the change set, and for each one the fields it
+  changes. A service's settings and its Kong routes are **one change set**, so
+  a route added earlier will be submitted by this submit too, and the user has
+  to see that before they agree to it. Mention a code only if the user asks,
+  or when they need it to run a command themselves.
 - A draft is not deployed. Say so, and name the next command
   (`request submit`, then `approval approve`, then `eks deploy`).
+- **After `request submit`, say three things.** That it is submitted and now
+  waiting for approval. How many rows moved and which kinds (settings,
+  gateway/Kong, variables) — the submit result's `requests[]` gives you both.
+  And who approves it next.
+  For that last one, do not guess and never write "if you have approval
+  rights": run `devlift request show <service> --env <env> --no-input -o json`
+  and read `you.can_approve`. If it is true, say plainly that they can approve
+  it themselves and offer `devlift approval approve <service> --env <env>`. If
+  it is false, say it needs a reviewer on that resource group. The user should
+  never have to work out their own permissions.
+- **After `approval approve`, show the approved change in full.** This is the
+  last checkpoint before anything reaches a cluster, so a queue code and the
+  word "approved" are not enough. Run `devlift request show <service> --env
+  <env> --no-input -o json` and show its frozen diff — every row, Field, From,
+  To — so the user sees exactly what is now cleared to ship. Then read
+  `you.can_deploy` from that same output: if true, say they can deploy it and
+  offer `devlift eks deploy <service> --env <env>` (`--wait` follows it to the
+  end); if false, say a deployer has to run it. Check, never guess, exactly as
+  with approval.
+- **After `eks deploy`, show what is shipping and where it has got to.** Run
+  `devlift deployment status <workflow-id> --no-input -o json` and show its
+  pipeline stages as the command gives them — each stage with its status and
+  timing — so the user can see which step is running rather than reading a
+  sentence about it. Say what is being deployed, which is the change that was
+  just approved, and keep the workflow id visible because every later check
+  needs it. Then name both follow-ups and the difference between them:
+  `deployment status <workflow-id> --wait` says when DevLift's own pipeline
+  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.
+- **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
+  two labels for the SAME cluster. Use `cluster` when you talk about it, and
+  never tell a user their services are on different clusters because the
+  strings differ — check with `devlift clusters list` before claiming any such
+  thing. That list is already narrowed to registered clusters a service can
+  actually be created on, so it is the authority.
+- Resources behave differently. `s3`, `sqs` and `dynamodb` create and update
+  deploy straight away, so there report the resource name and the workflow id,
+  which is what `deployment status` needs.
 - On exit 7 quote the message: it names the conflicting request or the rule
   (one live request per service, one auth per Kong tag, a name that exists).
 - On exit 2 stop and tell the user to sign in; on exit 4 say who to ask.

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

@@ -42,12 +42,18 @@ devlift repositories branches Regobs/orders --no-input -o json | jq -r '.[].name
 devlift languages list --no-input -o json
 devlift eks create --name orders --app core --env stage --region mumbai --type api \
   --repo Regobs/orders --branch main --language go --version 1.24 --no-input -o json 2>&1   # exit 5: two tables (service, configuration with From column) on stderr
-# SHOW the Configuration table to the user and ASK: "These are the standard Go values. Apply them, or tell me what to change?"
+# PASTE BOTH TABLES VERBATIM into your reply, in a code block, every row, before anything else you write.
+# They are the summary — a prose rewrite hides the values the user is about to approve. Commentary goes after them.
+# Then ASK: "These are the standard Go values. Apply them, or tell me what to change?"
 # a change becomes --set on the rerun, e.g. --set cpu_limit=0.5 --set hpa_enabled=true --set min_replicas=1 --set max_replicas=3
 devlift eks create … --no-input -y -o json
 # → {service_code, service_config_code, queue_code, queue_status: "draft", config}
+devlift request show orders --env stage --no-input -o json   # what now waits for review
 ```
-Then tell the user it is a draft and continue with workflow 6.
+Report what `request show` lists — the rows in the change set and the fields
+each changes. Do NOT report service_code / service_config_code / queue_code:
+they are plumbing for your next call, not something a person reads. Then tell
+the user it is a draft, nothing is deployed, and continue with workflow 6.
 `--type worker` drops health/service_path/ALB fields (no load balancer).
 
 ## 4. Change a running service's settings
@@ -74,22 +80,48 @@ the other auth → exit 7: pick another `--tag`.
 ## 6. Review lane (settings and routes move together)
 
 ```
+devlift request show orders --env stage --no-input -o json               # EVERYTHING that submit will send: settings AND Kong routes
 devlift request list --service orders --env stage --no-input -o json     # what exists, statuses, you.can_approve / can_deploy
 devlift request submit orders --no-input -y -o json                      # → requests[] all "submit"; exit 7 if another author holds the lane
+devlift request show orders --env stage --no-input -o json               # after submit: you.can_approve says whether THIS user may approve it
 devlift approval list --no-input -o json                                 # reviewer inbox
 devlift request show orders --no-input -o json                           # frozen diff for the reviewer
 devlift approval approve orders --no-input -y -o json                    # → requests[] all "approved"
+devlift request show orders --env stage --no-input -o json               # after approve: the frozen diff to show, and you.can_deploy
 # alternatives: approval request-changes orders --comment "…" -y ; approval reject orders --comment "…" -y ; approval revoke orders -y ; request withdraw orders -y
 ```
+Before submitting, show the user what `request show` lists and get their
+go-ahead. Submit moves the WHOLE change set, so a Kong route added earlier
+ships with the settings change; someone who only remembers editing CPU must
+not discover the route at approval time.
+
+After submitting, report that it is waiting for approval, how many rows moved
+and of which kinds, and who approves next. Read `you.can_approve` from
+`request show` rather than writing "if you have approval rights" — the CLI
+knows, so the user should not have to.
+
+After approving, show the frozen diff in full (every row, Field | From | To):
+approval is the last checkpoint before a cluster, and "approved" on its own
+tells the user nothing about what they just cleared. Then read `you.can_deploy`
+the same way to say whether they can ship it themselves.
+
 Self-approval works only where the resource group's rule allows it (403 → exit 4 otherwise).
 
 ## 7. Deploy and verify
 
 ```
 devlift eks deploy orders --env stage --no-input                         # lists approved rows, exit 5
-devlift eks deploy orders --env stage --no-input -y --wait -o json       # → {workflow_id, status, state}
+devlift eks deploy orders --env stage --no-input -y -o json              # → {workflow_id, requests[]}
+devlift deployment status <workflow_id> --no-input -o json               # stages with status + timing, pr_url, resources
 devlift eks status orders --env stage --no-input -o json                 # .deployment (stages, pr_url) and .application (ArgoCD state)
 ```
+After deploying, show the pipeline stages as the command gives them, each with
+its status and timing, plus what is shipping and the workflow id. Do not
+replace the stage list with a sentence: the user wants to see which step is
+running. Name both follow-ups and the difference — `deployment status --wait`
+answers "did DevLift's pipeline finish", `eks status` also asks ArgoCD "is the
+pod serving". A finished pipeline is not a running application.
+
 Production: `--confirm-name orders` in place of relying on `-y`.
 Read `.application.state`: `up` = healthy pod; `waiting_for_argocd` /
 `starting` = keep polling (`--wait`); `not_configured` = no ArgoCD for that

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

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