mcloud-local

Exécuter mcloud local build pour reproduire une build Cloud sur la machine locale. À utiliser lors du débogage d'un déploiement dont la build a échoué, sans pousser vers la branche suivie,…

npx skills add https://github.com/medusajs/medusa-agent-skills --skill mcloud-local

Cloud CLI: Local Command

Execute mcloud local build to run a Cloud build on the local machine, mirroring how Cloud builds the project. Use it to debug build-failed deployments without pushing changes and waiting for a full Cloud build.

Constraints

  • No --json flag. local build streams plaintext build output and signals the result through its exit code (0 = success). Do not parse its output as JSON.
  • Requires Docker installed and running, and must run from inside the project's Git repository.
  • Reproduces build-failed (build) failures only — not deployment-failed (runtime) failures. For runtime failures, use mcloud logs --deployment <id>.
  • Available since mcloud CLI v0.1.10.
  • The Docker build cache is disabled by default so variable changes always invalidate the cache; pass --docker-cache to enable it.

Command

local build

Run a Cloud build locally. Infers the root path and build variables from the linked Cloud project and environment. Builds the backend by default; pass --type storefront for the storefront.

mcloud local build \
  --organization <org-id> \
  --project <project-id-or-handle> \
  --environment <environment-handle>

Options:

  • -o/--organization <id> — Organization ID (falls back to active context)
  • -p/--project <id-or-handle> — Project ID or handle (falls back to active context)
  • -e/--environment <handle> — Environment whose variables are used (falls back to active context)
  • -t/--type <backend|storefront> — Build type (default: backend)
  • --root-path <path> — Backend root path relative to the repo root (inferred if omitted; . if no Cloud project found)
  • --storefront-path <path> — Storefront path relative to the repo root, for --type storefront (inferred if omitted)
  • --env-file <path> — Use a local .env file instead of the Cloud environment's variables
  • -v/--var <KEY=VALUE> — Override a single build variable; repeatable
  • --docker-cache — Enable the Docker build cache (default: false)

Output:

  • On success (exit 0), the backend image is tagged <repository-name>:cloud-local-build-<commit-hash>; a storefront build writes its output directory and prints the path.
  • On failure (non-zero exit), the command exits with the failing step's error — debug it as you would a Cloud build.

Reproduce a Build Failure

Check out the same commit the failed deployment built so the local build matches, then route on the exit code:

# Identify the failing deployment and the commit it built
DEPLOYMENT_ID=$(
  mcloud deployments list --json \
    | jq -r '[.[] | select(.backend_status == "build-failed")][0].id'
)
COMMIT=$(mcloud deployments get "$DEPLOYMENT_ID" --json | jq -r '.commit_hash')

git checkout "$COMMIT"

if mcloud local build; then
  echo "Build succeeded locally; failure not reproducible from this commit."
else
  echo "Build failed locally; inspect the streamed output for the failing step."
fi

Once the local build exits 0, push the fix to the tracked branch and start a fresh Cloud build with mcloud environments trigger-build <env>.

Examples

# Reproduce the backend build for the active context
mcloud local build

# Reproduce the storefront build
mcloud local build --type storefront --storefront-path apps/storefront

# Test a build-variable fix without editing code
mcloud local build --var NODE_ENV=production

# Build against a local .env file
mcloud local build --env-file .env

# Reuse the Docker cache for a faster rebuild
mcloud local build --docker-cache

Plus de skills de medusajs

creating-agents-in-medusa
medusajs
À utiliser lors de la création d'un agent IA interne destiné à l'administration dans un projet Medusa. Ces agents sont utilisés par les marchands et les opérateurs de boutique — pas par les clients. Couvre…
reviewing-prs
medusajs
Examine les pull requests GitHub du dépôt Medusa. Vérifie la conformité au modèle de PR, les directives de contribution, les conventions de code, la sécurité, les performances, et…
writing-releases
medusajs
Rédige les notes de version GitHub pour les versions de Medusa dans le style établi. À utiliser lors de la génération d'un brouillon de description de version à partir d'une liste de commits et de PR…
writing-tsdocs
medusajs
Ajoute et met à jour les commentaires TypeDoc (TSDoc) dans les fichiers source TypeScript du codebase de Medusa. Couvre les types HTTP, les routes API, les composants UI, les modèles de données, les services…
mcloud-variables
medusajs
Exécute les commandes mcloud variables pour lister et obtenir les variables d'environnement d'un environnement Cloud. À utiliser lors de l'inspection, de la lecture ou de l'exportation de variables d'environnement…
mcloud-deployments
medusajs
Exécutez les commandes mcloud deployments pour lister les déploiements, récupérer les détails d’un déploiement et obtenir les journaux de build. Utilisez cette commande pour lister les déploiements, vérifier l’état d’un déploiement…
writing-docs
medusajs
Rédige et met à jour les fichiers de documentation MDX de Medusa pour les projets book, resources, ui, user-guide et cloud. À utiliser lors de modifications de documentation basées sur…
building-storefronts
medusajs
Intégration frontend SDK-first pour les storefronts Medusa avec les motifs React Query et les règles critiques d'appel API. Utilisez toujours le SDK JS Medusa pour toutes les requêtes API — n'utilisez jamais fetch() standard, car il manque les en-têtes requis (clé API publiable pour les routes store, auth pour les routes admin). Passez des objets JavaScript simples aux méthodes SDK ; n'utilisez jamais JSON.stringify() sur les paramètres du corps, car le SDK gère la sérialisation automatiquement. Utilisez useQuery pour les requêtes GET et useMutation pour les requêtes POST/DELETE,...