mozbridge-cli 0.2.0__tar.gz → 0.3.0__tar.gz

{mozbridge_cli-0.2.0 → mozbridge_cli-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mozbridge-cli
-Version: 0.2.0
+Version: 0.3.0
 Summary: Command-line client for the Mozbridge deployment platform: SSO login, build, publish, status, and rollback for any project hosted on Mozbridge.
 Project-URL: Homepage, https://mozbridge.com
 Project-URL: Documentation, https://github.com/jessin01/mozbridge/blob/main/cli/docs/commands.md

{mozbridge_cli-0.2.0 → mozbridge_cli-0.3.0}/docs/commands.md

@@ -547,6 +547,196 @@ Rollback triggered (task_id=777).
 
 ---
 
+## `mozbridge deploy`
+
+Deploys an already-built image tag to the linked Mozbridge project. A real,
+consequential production action — same category as `mozbridge rollback`: it
+mutates production the moment it's called, **not a dry-run**. Prompts for
+confirmation unless `--yes` is given.
+
+**Flags**:
+| Flag | Meaning |
+|---|---|
+| `--frontend TAG` | Frontend image tag to deploy. |
+| `--backend TAG` | Backend image tag to deploy. |
+| `--env NAME` | Environment to deploy to. Default `prod`. |
+| `--force` | Override a blocking preflight check. Never set automatically — a separate, explicit decision each time. |
+| `--yes` | Skip the interactive confirmation prompt. |
+
+**Requires**: link + login, same as `publish`/`status`/`rollback`. At least
+one of `--frontend`/`--backend` must be given — deploying neither makes no
+sense.
+
+**What it does**: prints what it's about to do (project, which service(s),
+which tag(s), which environment), then either aborts on a declined prompt or
+calls `POST /api/v1/projects/{project_id}/deploy` with
+`{frontend_version, backend_version, services, environment, force}`.
+**`services` is built from which of `--frontend`/`--backend` you actually
+gave a tag** — not the API's own default of deploying both — so the CLI only
+ever asks the platform to deploy what you specified.
+
+The backend runs a preflight check before enqueuing the deploy. A 409
+response means it found a real, known-to-fail condition and refused —
+each blocking check is printed with its title, detail, and suggested
+action, followed by a hint to re-run with `--force` if you want to override
+it. **The CLI never retries with `--force` automatically** — that is always
+a separate, explicit re-invocation.
+
+**Example (`--yes`, single service)**:
+```
+$ mozbridge deploy --backend v1.9.319 --yes
+This will deploy acme/web-app (prod):
+  backend  -> v1.9.319
+Deploy triggered (task_id=888).
+Run `mozbridge logs` to watch it.
+```
+
+**Example (preflight blocked)**:
+```
+$ mozbridge deploy --backend v1.9.319 --yes
+This will deploy acme/web-app (prod):
+  backend  -> v1.9.319
+Preflight failed — this deploy is known to fail.
+  - No registry credential: GHCR_TOKEN is not configured for this project.
+    action: Set a registry credential in Project Settings.
+Pass force=true to deploy anyway.
+Re-run with --force to override — this is not done automatically.
+```
+
+**Failure modes**:
+- Neither `--frontend` nor `--backend` given: clear error, exit 1, no API
+  call is made.
+- Not linked / not logged in: identical messages to `publish` above, exit 1.
+- Confirmation prompt declined (`--yes` not passed, answer is not `y`):
+  Typer's own `Abort` handling — the command exits non-zero without calling
+  the API.
+- Preflight-blocked (409, structured body): every blocking check printed
+  clearly plus a `--force` hint, exit 1 — no automatic retry.
+- Any other API error: the raw `ApiError` message, exit 1.
+
+---
+
+## `mozbridge logs`
+
+Shows **BUILD/DEPLOY OPERATION logs** for the linked project — the log
+output of a Mozbridge build or deploy task (what `publish`, `deploy`, and
+`rollback` trigger). **This is not your running application's
+runtime/request logs** — the platform does not expose those via any API
+today, and this command is not `docker logs` for your live app.
+
+**Flags**:
+| Flag | Meaning |
+|---|---|
+| `TASK_ID` (argument, optional) | Task id of a build/deploy operation. Omit to use the most recent one for this project. |
+| `--follow` / `-f` | Stream new log output as it arrives; exits when the run finishes. |
+
+**Requires**: link + login, same as `status`/`diff`/`rollback`.
+
+**What it does**:
+- If `TASK_ID` is omitted: `GET /api/v1/projects/{project_id}/operations?limit=1`
+  (newest-first, same ordering `status`/`diff` already rely on for
+  deployments) to resolve the most recent operation's `task_id`.
+- Without `--follow`: one `GET /api/v1/projects/operations/{task_id}` call,
+  printing whatever is in `result.logs` right now — a single snapshot, no
+  long-lived connection.
+- With `--follow`: opens `GET /api/v1/projects/operations/{task_id}/stream`
+  (SSE) and prints each `log` event's content as it's parsed. The server
+  closes the stream itself once the operation reaches a terminal state
+  (success/failed/error) — the CLI exits cleanly at that point. A dropped
+  connection surfaces a clear error instead of hanging.
+
+**Example (snapshot)**:
+```
+$ mozbridge logs task-123
+Step 1/5 : FROM python:3.12
+Step 2/5 : COPY . /app
+```
+
+**Example (follow)**:
+```
+$ mozbridge logs task-123 --follow
+Step 1/5 : FROM python:3.12
+Step 2/5 : COPY . /app
+Successfully built abc123
+```
+
+**Failure modes**:
+- Not linked / not logged in: identical messages to `publish` above, exit 1.
+- No `TASK_ID` given and the project has no operations yet: `No operations
+  found for this project yet.`, exit 1.
+- The operation lookup or stream request fails: the raw `ApiError` message
+  (snapshot mode) or `Log stream connection dropped: <error>` (`--follow`),
+  exit 1.
+
+---
+
+## `mozbridge env list` / `mozbridge env set` / `mozbridge env rm`
+
+Manages the linked project's environment variables
+(`GET`/`POST`/`DELETE /api/v1/projects/{project_id}/env-vars[...]`).
+`EnvVar` is a plain `{key, value}` pair — distinct from the project's
+separate Vault-backed secrets blocks — and nothing in the platform's own
+dashboard UI masks these values, so `env list` prints them in plain text.
+
+**Requires**: link + login, same as `status`/`diff`/`rollback`.
+
+### `mozbridge env list`
+
+**Flags**: none.
+
+**What it does**: `GET /api/v1/projects/{project_id}/env-vars`, prints every
+key/value pair sorted by key. Prints `No environment variables set.` if
+there are none.
+
+```
+$ mozbridge env list
+  DATABASE_URL  postgres://user:pass@host/db
+  DEBUG         false
+```
+
+### `mozbridge env set KEY VALUE`
+
+**What it does**: `POST /api/v1/projects/{project_id}/env-vars` with body
+`{"key": KEY, "value": VALUE}`. **This is an upsert, not create-only** —
+read directly off `backend/app/security.py:store_project_env_var`: the
+handler loads the existing key->value dict out of Vault, does
+`existing[key] = value`, and writes the whole dict back. Setting an
+already-existing `KEY` silently overwrites it; there is no 409/400 and no
+separate create-vs-update codepath.
+
+The confirmation deliberately prints only the key, never the value, so a
+secret-shaped `VALUE` isn't echoed a second time into your terminal beyond
+the command invocation itself:
+
+```
+$ mozbridge env set DATABASE_URL postgres://user:pass@host/db
+Set DATABASE_URL.
+```
+
+### `mozbridge env rm KEY`
+
+**What it does**: `DELETE /api/v1/projects/{project_id}/env-vars/{KEY}`.
+**This is idempotent, not a strict "must exist" delete** — read directly
+off `backend/app/security.py:delete_project_env_var`: it deletes `KEY`
+`if key in existing`, and otherwise falls straight through to `return
+True` — either way the route responds 200. Removing a `KEY` that was never
+set still reports success; there is no 404 for a missing key, and this
+command does not invent one.
+
+```
+$ mozbridge env rm DATABASE_URL
+Removed DATABASE_URL.
+```
+
+**Failure modes (all three)**:
+- Not linked / not logged in: identical messages to `publish` above, exit 1.
+- Any other API error (e.g. a 500 from a Vault write/delete failure): the
+  raw `ApiError` message (`Could not list env vars: <detail>` / `Could not
+  set the env var: <detail>` / `Could not remove the env var: <detail>`),
+  exit 1.
+
+---
+
 ## A note on authorization for `publish` / `rollback`
 
 Both commands work today because a plain human Logto session token passes

{mozbridge_cli-0.2.0 → mozbridge_cli-0.3.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "mozbridge-cli"
-version = "0.2.0"
+version = "0.3.0"
 description = "Command-line client for the Mozbridge deployment platform: SSO login, build, publish, status, and rollback for any project hosted on Mozbridge."
 readme = "README.md"
 requires-python = ">=3.10"

{mozbridge_cli-0.2.0 → mozbridge_cli-0.3.0}/scripts/release.sh

@@ -10,8 +10,25 @@
 set -euo pipefail
 
 ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+REPO_ROOT="$(cd "$ROOT/.." && pwd)"
 PYPROJECT="$ROOT/pyproject.toml"
 
+# Hard first check: `git fetch` updates the remote-tracking ref, not the
+# working tree — only merge/rebase/pull do that. mozbridge-cli 0.2.0 was
+# published missing 3 commands because this build ran between a `git
+# fetch` and the merge that would have actually updated the checkout.
+# Refuse to build from a checkout that's behind origin/main.
+if command -v git >/dev/null 2>&1 && git -C "$REPO_ROOT" rev-parse --git-dir >/dev/null 2>&1; then
+  git -C "$REPO_ROOT" fetch origin main --quiet 2>/dev/null || true
+  BEHIND="$(git -C "$REPO_ROOT" rev-list --count HEAD..origin/main 2>/dev/null || echo 0)"
+  if [ "${BEHIND:-0}" != "0" ]; then
+    echo "✗ Local main is ${BEHIND} commit(s) behind origin/main." >&2
+    echo "  Run: git -C \"$REPO_ROOT\" merge --ff-only origin/main" >&2
+    echo "  then re-run this script. Refusing to build a stale release." >&2
+    exit 1
+  fi
+fi
+
 usage() {
   echo "Usage: $0 [--patch|--minor|--major] [--dry-run]" >&2
   echo "  Default bump: patch" >&2