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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mozbridge-cli
-Version: 0.8.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.8.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.8.0 → mozbridge_cli-0.9.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "mozbridge-cli"
-version = "0.8.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.8.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.8.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

{mozbridge_cli-0.8.0 → mozbridge_cli-0.9.0}/src/mozbridge_cli/cmd_publish.py

@@ -15,7 +15,7 @@ from . import link as linkmod
 from . import local_build as local_buildmod
 from . import runtime_secrets as runtime_secretsmod
 from .cmd_auth import load_and_refresh_session
-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)
 
@@ -104,6 +104,80 @@ def _publish_single_component(
     typer.echo("Run `mozbridge status` to check progress, or poll the Mozbridge dashboard.")
 
 
+def _publish_site(
+    client: httpx.Client,
+    active_session: session.Session,
+    current_link: linkmod.Link,
+    cwd: Path,
+    project: dict,
+) -> None:
+    """`mozbridge publish` for a Launch site (shape=site): the site-shaped
+    counterpart of `_publish_single_component` above — same shape (zip -> create
+    an upload session -> PUT the bytes -> tell the backend to consume it), but
+    against the site-only endpoints, and it always publishes immediately (no
+    build to enqueue, no task to poll for a docker image; the platform serves
+    the zip's contents directly).
+
+    Uses the EXACT SAME zip (`buildmod.build_zip`) as `mozbridge build` and the
+    app-build path above — no separate zipping logic for sites.
+    """
+    result = buildmod.build_zip(cwd)
+    typer.echo(f"Built {result.zip_path} ({result.size_bytes / 1024:.1f} KB, {result.file_count} files)")
+    try:
+        try:
+            upload_session = api.create_publish_upload(
+                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)
+
+        zip_bytes = result.zip_path.read_bytes()
+        try:
+            api.put_publish_upload_bytes(
+                client,
+                active_session.access_token,
+                current_link.org_id,
+                upload_session["put_url"],
+                zip_bytes,
+            )
+        except api.ApiError as exc:
+            typer.echo(str(exc), err=True)
+            raise typer.Exit(code=1)
+    finally:
+        result.zip_path.unlink(missing_ok=True)
+
+    try:
+        publish_response = api.publish_from_upload(
+            client,
+            active_session.access_token,
+            current_link.org_id,
+            current_link.project_id,
+            upload_session["upload_id"],
+            immediate=True,
+        )
+    except api.ApiError as exc:
+        typer.echo(str(exc), err=True)
+        raise typer.Exit(code=1)
+
+    task_id = publish_response.get("task_id")
+    revision = publish_response.get("revision") or ""
+    typer.echo(f"Site publish triggered (task_id={task_id}, revision={revision[:12]}).")
+
+    # The publish response itself never carries the site's live URL (see
+    # api.publish_from_upload's docstring) — it's the project's own domain,
+    # which we already have from the get_project call publish_cmd made to
+    # resolve the project's shape in the first place. This is the actual
+    # deliverable of a site publish, so it gets its own clearly-labeled line.
+    domain = project.get("domain")
+    if domain:
+        typer.echo(f"Site: https://{domain}")
+    typer.echo("Run `mozbridge status` to check progress, or poll the Mozbridge dashboard.")
+
+
 def _publish_multi_component(
     client: httpx.Client,
     active_session: session.Session,
@@ -199,21 +273,32 @@ def publish_cmd(
     Requires `mozbridge link` to have been run here, and an active login
     session.
 
-    If a compose file is present (docker-compose.yml, compose.yaml, or
-    docker-compose.yaml — Docker's own discovery order) and at least one of
-    its services has a `build:` key, each such service is published as its
-    own component/image: one create_source_upload -> PUT -> trigger_build
-    per component, with contexts shared across services de-duplicated to a
-    single upload. Otherwise (no compose file, or none of its services
-    build) this falls back unchanged to the original single-component flow:
-    zip the whole directory, one upload, one trigger_build call.
+    First resolves the linked project's shape (one cheap `get_project` call)
+    and branches:
+
+    - **Site-shaped** (Launch site, `config.shape == "site"`): zips the whole
+      directory and publishes it as a static site — see `_publish_site`
+      below. None of the compose/component logic below applies; a site has
+      no Docker image to build.
+    - **App-shaped** (everything else, the original behavior, unchanged): if
+      a compose file is present (docker-compose.yml, compose.yaml, or
+      docker-compose.yaml — Docker's own discovery order) and at least one of
+      its services has a `build:` key, each such service is published as its
+      own component/image: one create_source_upload -> PUT -> trigger_build
+      per component, with contexts shared across services de-duplicated to a
+      single upload. Otherwise (no compose file, or none of its services
+      build) this falls back unchanged to the original single-component flow:
+      zip the whole directory, one upload, one trigger_build call.
 
     `--local` replaces the upload+remote-build step entirely: components are
     resolved the same way, but each is built and pushed with the developer's
     own local `docker`, using registry credentials fetched with a SEPARATE
     build-scoped token (MOZBRIDGE_BUILD_TOKEN), then registered via the same
     trigger_build endpoint using the regular login session. See
-    `_publish_local` below.
+    `_publish_local` below. `--local` has no meaning for a site-shaped
+    project (sites don't build a Docker image at all) — `_publish_local`
+    checks this itself and fails immediately, before any docker or upload
+    call, if the linked project turns out to be a site.
     """
     cwd = Path.cwd()
     current_link = linkmod.load_link(cwd)
@@ -227,14 +312,26 @@ def publish_cmd(
         _publish_local(cwd, current_link)
         return
 
-    components: list[composemod.Component] = []
-    compose_path = composemod.find_compose_file(cwd)
-    if compose_path is not None:
-        components = composemod.parse_components(compose_path)
-
     with httpx.Client(timeout=120.0) as client:
         active_session = load_and_refresh_session(client)
 
+        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):
+            _publish_site(client, active_session, current_link, cwd, project)
+            return
+
+        components: list[composemod.Component] = []
+        compose_path = composemod.find_compose_file(cwd)
+        if compose_path is not None:
+            components = composemod.parse_components(compose_path)
+
         if components:
             typer.echo(f"Using {compose_path.name} for multi-component publish.")
             groups = composemod.resolve_components(
@@ -256,7 +353,11 @@ def _publish_local(cwd: Path, current_link: linkmod.Link) -> None:
     Order of checks is deliberate: cheap, local, no-network checks first
     (MOZBRIDGE_BUILD_TOKEN present, docker installed/daemon reachable) so a
     misconfigured environment fails fast with zero docker or HTTP calls,
-    before login-session refresh or any network call is attempted.
+    before login-session refresh or any network call is attempted. The one
+    network-shaped check that can't be done locally — is this project even a
+    site, which makes `--local` meaningless — runs right after session
+    refresh, still before runtime-secrets/docker-login/build/push, so a site
+    project fails clearly without ever touching docker or a registry.
     """
     build_token = os.environ.get(runtime_secretsmod.BUILD_TOKEN_ENV_VAR)
     if not build_token:
@@ -288,6 +389,22 @@ def _publish_local(cwd: Path, current_link: linkmod.Link) -> None:
     with httpx.Client(timeout=180.0) as client:
         active_session = load_and_refresh_session(client)
 
+        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(
+                "--local is for app builds; sites don't use Docker — run `mozbridge publish` "
+                "without --local.",
+                err=True,
+            )
+            raise typer.Exit(code=1)
+
         try:
             secrets = runtime_secretsmod.fetch_runtime_secrets(client, build_token)
         except runtime_secretsmod.RuntimeSecretsError as exc:
@@ -410,21 +527,34 @@ def diff_cmd() -> None:
     """Preview what `mozbridge publish` would do right now. Does not publish anything.
 
     Requires `mozbridge link` and an active login session, same as `publish`.
-    Makes no mutating API calls: it only GETs the linked project's most
-    recent deployment (the same call `mozbridge status` makes) for context,
-    plus local filesystem reads to work out what `publish` would build. No
-    upload, no trigger_build.
+    Makes no mutating API calls: it only GETs the linked project itself (to
+    resolve its shape) and its most recent deployment (the same call
+    `mozbridge status` makes) for context, plus local filesystem reads to
+    work out what `publish` would build. No upload, no trigger_build.
 
     This compares local components against the most recent deployment
     RECORD only — the platform does not expose the actually-deployed
     compose content anywhere, so this is not a full semantic compose diff,
-    just "here's what's live" next to "here's what publish would build".
+    just "here's what's live" next to "here's what publish would build". For
+    a site-shaped project, the deployment-record list is normally empty even
+    after real publishes — see `mozbridge status`'s own known gap, the same
+    limitation applies here — and the compose/component analysis below is
+    skipped entirely in favor of a plain statement of what `publish` would
+    actually do for a site.
     """
     cwd = Path.cwd()
 
     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)
+
         try:
             deployments = api.list_project_deployments(
                 client, active_session.access_token, current_link.org_id, current_link.project_id
@@ -452,6 +582,15 @@ def diff_cmd() -> None:
         typer.echo("  No deployments yet.")
     typer.echo("")
 
+    if is_site_project(project):
+        typer.echo(
+            "This project is a Launch site — `mozbridge publish` would zip the current "
+            "directory and publish it as a static site (create a publish-upload session, "
+            "PUT the zip, then publish-from-upload with immediate=true), not build a Docker "
+            "image. The compose/component analysis below does not apply to Launch sites."
+        )
+        return
+
     components: list[composemod.Component] = []
     compose_path = composemod.find_compose_file(cwd)
     if compose_path is not None:

{mozbridge_cli-0.8.0 → mozbridge_cli-0.9.0}/src/mozbridge_cli/cmd_shared.py

@@ -29,3 +29,17 @@ def require_link_and_session(client: httpx.Client, cwd: Path) -> tuple[linkmod.L
         raise typer.Exit(code=1)
     active_session = load_and_refresh_session(client)
     return current_link, active_session
+
+
+def is_site_project(project: dict) -> bool:
+    """True when `project` (an api.get_project response) is a Launch site
+    (`config.shape == "site"`), not an app build.
+
+    Mirrors `backend/app/services/site_service.py`'s own `is_site_project` —
+    the ONE discriminator the backend uses everywhere to route between the
+    app-build and static-site code paths. Shape-aware commands
+    (`publish`, `publish --local`, `deploy`, `diff`) all call this against
+    whatever `api.get_project` already returned, rather than adding a second,
+    parallel "get the shape" endpoint.
+    """
+    return (project.get("config") or {}).get("shape") == "site"