mozbridge-cli 0.7.0__tar.gz → 0.9.0__tar.gz

{mozbridge_cli-0.7.0 → mozbridge_cli-0.9.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mozbridge-cli
-Version: 0.7.0
+Version: 0.9.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.7.0 → mozbridge_cli-0.9.0}/docs/commands.md

@@ -382,6 +382,96 @@ modes):
 
 ---
 
+## `mozbridge publish` — Launch sites (site-shaped projects)
+
+Everything under `## \`mozbridge publish\`` above describes the **app-build**
+path. A project can instead be **site-shaped** (a Launch site — static
+hosting only, `config.shape == "site"` on the project, set by `mozbridge
+create-site`/the dashboard's "Launch site" project type) — `publish`
+resolves this automatically and takes a structurally different path for it.
+This section is the site-shaped counterpart to everything above.
+
+**Flags**: `--local` — see below, it's rejected outright for a site.
+
+**Requires**: same as `publish` (link + login). No compose file / component
+discovery ever runs for a site — a Launch site has no Docker image.
+
+**What it does**:
+1. One extra call at the very start of `publish` (for *every* project, app or
+   site): `GET /api/v1/projects/{project_id}` to resolve
+   `config.shape` — the same one discriminator the backend itself uses
+   everywhere (`is_site_project`). This is the only new cost `publish` pays
+   for an app-shaped project — one cheap GET before it does exactly what it
+   always did.
+2. If `shape == "site"`: zips the current directory — the *exact same*
+   `build.build_zip` primitive `mozbridge build` and the app-build path use,
+   no separate site-zipping logic — then:
+   - `POST /api/v1/projects/{project_id}/publish-uploads` — creates a
+     short-lived upload session, returns `{upload_id, put_url, expires_at,
+     max_bytes, instructions}` (the site counterpart of `source-uploads`,
+     same response shape, different endpoint).
+   - `PUT {put_url}` — the raw zip bytes, `Authorization` + `X-Organization-Id`
+     + `Content-Type: application/zip`, same wire contract as the app-build
+     upload.
+   - `POST /api/v1/projects/{project_id}/publish-from-upload`, body
+     `{upload_id, immediate: true}` — consumes the upload and publishes it
+     right away. `immediate=true` is what this CLI always sends, for parity
+     with how `publish` already behaves for an app-shaped project (no
+     separate stage-then-confirm step).
+3. Prints the resulting task id/revision, then — since the
+   `publish-from-upload` response itself never carries the site's live URL —
+   the project's own `domain` (already known from step 1's `get_project`
+   call) as a clearly labeled `Site: https://...` line. This is the actual
+   deliverable of a site publish.
+
+**Example**:
+```
+$ mozbridge publish
+Built /tmp/mozbridge-build-a1b2.zip (12.4 KB, 4 files)
+Site publish triggered (task_id=abc123, revision=deadbeefcafe).
+Site: https://launchpage.mozbridge.com
+Run `mozbridge status` to check progress, or poll the Mozbridge dashboard.
+```
+
+**`--local` against a site fails immediately**: `--local` means "build and
+push a Docker image on this machine" — meaningless for a site, which has no
+Docker image at all. `_publish_local` checks the project's shape right after
+resolving the login session (still before `MOZBRIDGE_BUILD_TOKEN`'s
+runtime-secrets fetch, `docker login`, or any build/push) and, if the
+project is a site, fails immediately:
+```
+$ mozbridge publish --local
+--local is for app builds; sites don't use Docker — run `mozbridge publish`
+without --local.
+```
+No docker command and no HTTP call beyond the shape check itself is ever
+attempted.
+
+**Failure modes** (in addition to `publish`'s own not-linked/not-logged-in
+modes):
+- The shape-check `get_project` call itself fails: the raw `ApiError`
+  message (same pattern as every other command), exit 1 — nothing else is
+  attempted.
+- `create_publish_upload` fails: `Could not create a publish upload
+  session: <backend detail>`, exit 1.
+- The `PUT` upload fails: `Could not upload the site content: <backend
+  detail>`, exit 1 — `publish-from-upload` is never called if the upload
+  failed.
+- `publish-from-upload` itself fails: `Could not publish the site: <backend
+  detail>`, exit 1.
+- `--local` against a site: the clear message above, exit 1, no docker or
+  HTTP call beyond the shape check.
+
+**Known gap**: `mozbridge status`'s "recent deployments" list stays empty
+for a site even after real publishes — see `## \`mozbridge status\`` below.
+`mozbridge diff` describes the site-publish path in plain language instead
+of the compose/component analysis (see `## \`mozbridge diff\`` below).
+`mozbridge deploy` refuses outright for a site (see `## \`mozbridge
+deploy\`` below) — `mozbridge rollback` is unaffected, it already works
+identically for both shapes via one unified backend endpoint.
+
+---
+
 ## `mozbridge diff`
 
 A genuine dry-run/preview: shows what `mozbridge publish` would do right
@@ -393,15 +483,23 @@ now, without doing anything. Makes **no** mutating API call — GET-only
 **Requires**: link + login, same as `publish` and `status`.
 
 **What it does**:
-1. `GET /api/v1/projects/{project_id}/deployments` — same call `status`
-   makes — and prints the single most recent deployment record for
-   context (id, timestamp, `component=version`, status, `[stable]`).
-2. Discovers a compose file exactly as `publish` does (reusing
-   `compose.py`). If none is found, or one is found but none of its
-   services have a `build:` key, it says plainly that `publish` would fall
-   back to the single-component path (zip the whole directory) — this is
-   reported, not treated as an error.
-3. If components are found, prints each one's resolved
+1. `GET /api/v1/projects/{project_id}` to resolve the project (and its
+   shape — see the site-shaped behavior below), and `GET
+   /api/v1/projects/{project_id}/deployments` — same call `status` makes —
+   and prints the single most recent deployment record for context (id,
+   timestamp, `component=version`, status, `[stable]`).
+2. **Site-shaped project**: stops here and prints, in plain language, what
+   `mozbridge publish` would actually do for a site (zip the directory,
+   create a publish-upload session, PUT the bytes, publish-from-upload with
+   `immediate=true`) — none of the compose/component analysis below applies,
+   a Launch site has no Docker image to build. See `## \`mozbridge publish\`
+   — Launch sites` above for the real flow this describes.
+3. **App-shaped project** (unchanged): discovers a compose file exactly as
+   `publish` does (reusing `compose.py`). If none is found, or one is found
+   but none of its services have a `build:` key, it says plainly that
+   `publish` would fall back to the single-component path (zip the whole
+   directory) — this is reported, not treated as an error.
+4. If components are found, prints each one's resolved
    `image_name`/`context_path`/`dockerfile_path` — computed by the exact
    same `compose.resolve_components` function `publish` calls to build its
    `trigger_build` request bodies, so `diff`'s output can never silently
@@ -487,6 +585,14 @@ only when `is_stable` is true on that deployment. If there are no
 deployments at all, the project line still prints, followed by `No
 deployments yet.`
 
+**KNOWN GAP — Launch sites**: `/deployments` only ever returns rows written
+by the app-build deploy task; a site's own publish path never writes one.
+For a site-shaped project this command currently prints `No deployments
+yet.` even after several real publishes, even though the project's own
+config tracks its actual revision history. Not yet fixed — see the CLI
+site-project-support notes rather than assuming this is a bug specific to
+your project.
+
 **Failure modes**:
 - Not linked / not logged in: identical messages to `publish` above,
   exit 1.
@@ -500,6 +606,11 @@ deployments yet.`
 
 Rolls back the linked project's deployment. A real, consequential
 production action — prompts for confirmation unless `--yes` is given.
+Unlike `publish`/`deploy`, this command needs **no shape check** and no
+change for this feature: the backend already unifies app- and site-shaped
+rollback behind these same two endpoints
+(`rollback_project_or_site`/`rollback_to_specific`), so it already works
+identically for both.
 
 **Flags**:
 | Flag | Meaning |
@@ -567,7 +678,21 @@ confirmation unless `--yes` is given.
 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),
+**Not applicable to a Launch site**: a site has no image tag to deploy at
+all. Right after resolving the link/session — before the preflight check,
+before the confirmation prompt, before any deploy request — `deploy` checks
+the linked project's shape (`GET /api/v1/projects/{project_id}`) and, if
+it's a site, fails immediately:
+```
+$ mozbridge deploy --backend v1.9.319 --yes
+This project is a Launch site — sites deploy via `mozbridge publish`, not
+`mozbridge deploy` (there is no image tag to deploy for a site). Run
+`mozbridge publish` instead.
+```
+No preflight call and no deploy request is ever sent for a site — this
+never becomes a confusing raw 400 from the backend.
+
+**What it does** (app-shaped project): 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}`.
@@ -620,6 +745,10 @@ Re-run with --force to override — this is not done automatically.
 - 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.
+- The shape-check `get_project` call itself fails: the raw `ApiError`
+  message, exit 1 — nothing else is attempted.
+- Linked project is a Launch site: the clear message above, exit 1, no
+  preflight/deploy call ever sent.
 - Confirmation prompt declined (`--yes` not passed, answer is not `y`):
   Typer's own `Abort` handling — the command exits non-zero without calling
   the API.

{mozbridge_cli-0.7.0 → mozbridge_cli-0.9.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "mozbridge-cli"
-version = "0.7.0"
+version = "0.9.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.7.0 → mozbridge_cli-0.9.0}/src/mozbridge_cli/api.py

@@ -134,7 +134,16 @@ def put_source_upload_bytes(
 
 
 def get_project(client: httpx.Client, access_token: str, org_id: int, project_id: int) -> dict:
-    """GET /api/v1/projects/{project_id} — schemas.Project (name/slug/status/config/...)."""
+    """GET /api/v1/projects/{project_id} — schemas.Project (name/slug/status/config/...).
+
+    `config` (a plain dict, see schemas.Project) is what carries the project's
+    "shape" — `(project.get("config") or {}).get("shape") == "site"` for a
+    Launch site, absent/anything else for an app build. This is the SAME
+    discriminator the backend itself uses everywhere
+    (`app/services/site_service.py:is_site_project`), so callers needing to
+    branch on shape (see cmd_shared.is_site_project) should call this rather
+    than adding a second, parallel "get the shape" endpoint.
+    """
     url = f"{config.API_BASE_URL}{config.PROJECTS_PATH}/{project_id}"
     try:
         resp = client.get(url, headers=_headers(access_token, org_id))
@@ -144,6 +153,96 @@ def get_project(client: httpx.Client, access_token: str, org_id: int, project_id
     return resp.json()
 
 
+def create_publish_upload(client: httpx.Client, access_token: str, org_id: int, project_id: int) -> dict:
+    """POST /api/v1/projects/{project_id}/publish-uploads — Launch-site counterpart to
+    `create_source_upload` above.
+
+    Sites don't get a Docker build — they get a static-file publish
+    (`backend/app/features/projects/router.py`'s `create_publish_upload`,
+    ~line 464), 400s if the project isn't `shape=site` (`is_site_project`).
+
+    Returns the SAME shape as `create_source_upload`
+    ({upload_id, put_url, expires_at, max_bytes, instructions}) — the backend
+    reuses `schemas.SitePublishUploadSession` for both, so this is a distinct
+    function (not an alias) only because it hits a distinct, site-only route.
+    """
+    url = f"{config.API_BASE_URL}{config.PROJECTS_PATH}/{project_id}/publish-uploads"
+    try:
+        resp = client.post(url, headers=_headers(access_token, org_id))
+    except httpx.HTTPError as exc:
+        raise ApiError(f"Could not reach Mozbridge API: {exc}") from exc
+    _raise_for_status(resp, "create a publish upload session")
+    return resp.json()
+
+
+def put_publish_upload_bytes(
+    client: httpx.Client,
+    access_token: str,
+    org_id: int,
+    put_url: str,
+    data: bytes,
+) -> None:
+    """PUT the zip bytes to the put_url returned by create_publish_upload.
+
+    Same wire contract as `put_source_upload_bytes` above (Authorization +
+    X-Organization-Id + `application/zip` body) — the backend's
+    `put_publish_upload` route (router.py ~line 504) accepts the raw body the
+    same way `put_source_upload` does. Kept as a separate function (rather
+    than reusing `put_source_upload_bytes` directly) purely so a failure here
+    reads as "upload the site content", not "upload the build source" — the
+    two flows are conceptually distinct even though the bytes-on-the-wire
+    shape is identical.
+    """
+    try:
+        resp = client.put(
+            put_url,
+            content=data,
+            headers={**_headers(access_token, org_id), "Content-Type": "application/zip"},
+        )
+    except httpx.HTTPError as exc:
+        raise ApiError(f"Could not reach Mozbridge API: {exc}") from exc
+    _raise_for_status(resp, "upload the site content")
+
+
+def publish_from_upload(
+    client: httpx.Client,
+    access_token: str,
+    org_id: int,
+    project_id: int,
+    upload_id: str,
+    *,
+    immediate: bool = True,
+) -> dict:
+    """POST /api/v1/projects/{project_id}/publish-from-upload, body schemas.SitePublishFromUpload.
+
+    Consumes a ready `create_publish_upload` session and ingests it exactly
+    like the multipart publish endpoint (router.py's `publish_site_from_upload`,
+    ~line 612) — 400s if the project isn't `shape=site`.
+
+    `immediate` defaults True: this CLI's `publish` command always calls with
+    immediate=True, matching how `publish` already behaves for app-shaped
+    projects (no separate stage-then-confirm step) — see cmd_publish.py's
+    `_publish_site`. With immediate=True the revision is deployed right away
+    and the response's `status` comes back "queued" with `preview_url` unset;
+    with immediate=False (not currently used by this CLI, kept as a real
+    parameter rather than hardcoding True so a future `--stage` flag doesn't
+    need a new function) the revision is only staged, `status` comes back
+    "staged" and `preview_url` is populated instead.
+
+    Returns schemas.SitePublishResponse: {task_id, revision, status,
+    preview_url}. Note this response never carries the site's live URL —
+    that's `project.domain` (from `get_project`), not anything in this body.
+    """
+    url = f"{config.API_BASE_URL}{config.PROJECTS_PATH}/{project_id}/publish-from-upload"
+    payload = {"upload_id": upload_id, "immediate": immediate}
+    try:
+        resp = client.post(url, json=payload, headers=_headers(access_token, org_id))
+    except httpx.HTTPError as exc:
+        raise ApiError(f"Could not reach Mozbridge API: {exc}") from exc
+    _raise_for_status(resp, "publish the site")
+    return resp.json()
+
+
 def list_project_deployments(
     client: httpx.Client, access_token: str, org_id: int, project_id: int
 ) -> list[dict]:

{mozbridge_cli-0.7.0 → mozbridge_cli-0.9.0}/src/mozbridge_cli/auth.py

@@ -64,7 +64,11 @@ class DeviceAuthorization:
 def start_device_authorization(client: httpx.Client) -> DeviceAuthorization:
     resp = client.post(
         config.DEVICE_AUTH_URL,
-        data={"client_id": config.LOGTO_CLIENT_ID, "scope": config.DEVICE_SCOPE},
+        data={
+            "client_id": config.LOGTO_CLIENT_ID,
+            "scope": config.DEVICE_SCOPE,
+            "resource": config.LOGTO_RESOURCE,
+        },
     )
     resp.raise_for_status()
     data = resp.json()
@@ -89,6 +93,7 @@ def _poll_once(client: httpx.Client, device_code: str) -> dict | None:
             "client_id": config.LOGTO_CLIENT_ID,
             "grant_type": GRANT_TYPE_DEVICE_CODE,
             "device_code": device_code,
+            "resource": config.LOGTO_RESOURCE,
         },
     )
     if resp.status_code == 200:
@@ -166,6 +171,7 @@ def refresh_access_token(client: httpx.Client, refresh_token: str) -> dict:
             "grant_type": "refresh_token",
             "refresh_token": refresh_token,
             "client_id": config.LOGTO_CLIENT_ID,
+            "resource": config.LOGTO_RESOURCE,
         },
     )
     if resp.status_code == 200:

{mozbridge_cli-0.7.0 → mozbridge_cli-0.9.0}/src/mozbridge_cli/cmd_deploy.py

@@ -9,7 +9,7 @@ import httpx
 import typer
 
 from . import api
-from .cmd_shared import require_link_and_session
+from .cmd_shared import is_site_project, require_link_and_session
 
 app = typer.Typer(add_completion=False)
 
@@ -43,7 +43,20 @@ def _print_preflight_notice(preflight: dict) -> None:
 
 @app.command("status")
 def status_cmd() -> None:
-    """Show the linked project's status and its 5 most recent deployments."""
+    """Show the linked project's status and its 5 most recent deployments.
+
+    KNOWN GAP for a site-shaped (Launch site) project: `list_project_deployments`
+    only ever returns rows written by the app-build deploy task
+    (`models.ProjectDeployment`, created in `app/tasks.py`'s `deploy_project`
+    task) — a site's own publish path (`SiteService.ingest_zip` /
+    `_enqueue_deploy`, driven by `publish_static_site`) never writes one. So
+    for a site this command will print "No deployments yet." even after
+    several real publishes, even though the project's `config` (last_revision/
+    staged_revision/stable_revision) shows otherwise. Left unfixed
+    deliberately in this slice — see the CLI site-project-support docs for the
+    full reasoning — rather than guessed at without a confirmed design for
+    what a site's own "recent activity" list should look like.
+    """
     cwd = Path.cwd()
 
     with httpx.Client(timeout=30.0) as client:
@@ -171,6 +184,14 @@ def deploy_cmd(
     still proceeds to the normal confirmation flow — matching the
     backend's own fail-open design for this gate rather than being
     stricter than the platform itself is.
+
+    Not applicable to a site-shaped (Launch site) project: a site has no
+    image tag to deploy at all — `--frontend`/`--backend` are meaningless for
+    it. If the linked project turns out to be a site, this command fails
+    immediately (right after resolving the link/session, before the preflight
+    check or any deploy request) with a clear error pointing at `mozbridge
+    publish` instead — it never sends the nonsensical deploy request to the
+    backend and lets a raw API error stand in for that explanation.
     """
     if frontend is None and backend is None:
         typer.echo(
@@ -190,6 +211,23 @@ def deploy_cmd(
     with httpx.Client(timeout=30.0) as client:
         current_link, active_session = require_link_and_session(client, cwd)
 
+        try:
+            project = api.get_project(
+                client, active_session.access_token, current_link.org_id, current_link.project_id
+            )
+        except api.ApiError as exc:
+            typer.echo(str(exc), err=True)
+            raise typer.Exit(code=1)
+
+        if is_site_project(project):
+            typer.echo(
+                "This project is a Launch site — sites deploy via `mozbridge publish`, "
+                "not `mozbridge deploy` (there is no image tag to deploy for a site). "
+                "Run `mozbridge publish` instead.",
+                err=True,
+            )
+            raise typer.Exit(code=1)
+
         try:
             preflight = api.get_project_preflight(
                 client, active_session.access_token, current_link.org_id, current_link.project_id