Catalyst logoCommand linev0.2

CLI Catalyst

Pilotez Catalyst depuis votre terminal : connectez-vous d'un clic navigateur, vérifiez qu'un build va passer, puis lancez un build apk ou build ipa (signé ou non) — le calcul tourne sur nos serveurs.

La CLI expose la même API publique que l'application web. Un seul binaire catalyst, publié sur deux registres avec un comportement identique — choisissez celui de votre écosystème.

Installation

Via npm (couvre aussi pnpm / yarn / bun — même registre) :

npm install -g catalyst-cli
# ou :  pnpm add -g catalyst-cli  ·  yarn global add catalyst-cli

Via pip (Python ≥ 3.8) :

pip install catalyst-cli

Vérifiez l'installation :

catalyst --version
catalyst --help

Connexion : login

catalyst login ouvre votre navigateur sur la page de connexion. Si vous n'êtes pas connecté, le site vous y invite ; sinon il vous demande simplement d'autoriser la CLI. Un jeton personnel (PAT) est créé, renvoyé à la CLI et stocké localement — vous n'avez rien à copier-coller.

catalyst login
Comment ça marche
La CLI démarre un petit serveur local éphémère sur 127.0.0.1, ouvre la page /cli-auth, et reçoit le jeton en retour (protégé par un nonce aléatoire : seule la fenêtre que vous venez d'ouvrir peut compléter la connexion). La session est écrite dans ~/.catalyst/config.json (permissions 600), partagée par les versions npm et pip.

Connexion sans navigateur (SSH / headless)

Sur une machine distante sans navigateur, deux options :

# 1. Coller un jeton généré sur un autre appareil :
catalyst login --no-browser

# 2. Fournir directement un PAT (scripts, CI/CD) :
catalyst login --token cat_xxxxxxxx_yyyyyyyyyyyyyyyy
OptionEffet
--no-browserN'ouvre pas de navigateur : affiche l'URL à ouvrir ailleurs et attend que vous colliez le jeton.
--token <pat>Enregistre directement un jeton existant, sans interaction (idéal en CI).
--api <url>Cible une instance précise (self-hosted) au lieu de l'API par défaut.

Qui suis-je : whoami

Affiche l'utilisateur connecté, l'API utilisée et d'où vient le jeton (session, variable d'environnement ou option).

catalyst whoami
# → Logged in as you@example.com
#     api:   https://dev.bcat.website/catalyst/api
#     token: cat_ab12cd34…  (from ~/.catalyst/config.json)

Déconnexion : logout

Révoque le jeton côté serveur (il devient inutilisable) puis efface la session locale. Relancez catalyst login pour vous reconnecter ou changer de compte.

catalyst logout
# --keep-token : oublier seulement en local, sans révoquer côté serveur

Session, priorité & configuration

Pour chaque commande, l'API et le jeton sont résolus dans cet ordre (le premier trouvé gagne) :

PrioritéSourceExemple
1Option de commande--token cat_… / --api …
2Variable d'environnementCATALYST_TOKEN / CATALYST_API
3Session stockée par login~/.catalyst/config.json
4Valeur par défaut (prod)aucune configuration requise
VariableRôle
CATALYST_TOKENJeton personnel (PAT) à utiliser.
CATALYST_APIBase de l'API (ex. instance self-hosted).
CATALYST_APP_URLURL du site à ouvrir au login (si distincte de l'API).
CATALYST_CONFIG_DIRDossier de la session (défaut : ~/.catalyst).
Variables d'environnement reconnues par la CLI.

Vérification préflight : check

Avant d'uploader et de builder, catalyst check vous dit en moins de 2 minutes si le build va passer ou être bloqué : contrôles locaux (projet vide, package.json invalide, lockfile manquant, fichiers trop lourds) puis contrôles serveur (framework détecté, cible compatible, quota / plan, durée estimée) — les mêmes règles que le vrai déclenchement.

catalyst check ./my-app --target android
#   [ ok ] files: 39 files, 1 MB after filtering
#   [ ok ] lockfile: package-lock.json found — deterministic install
#   [ ok ] server:target: expo → android supported
#   [ ok ] eta: similar expo/android builds take ~7m30s
#
#   SHOULD BUILD — no blocker found (3s).
OptionEffet
--target web|ios|androidCible à vérifier (défaut : cible par défaut du framework).
--signing-mode unsigned|signedVérifie aussi que la signature est configurée pour un build signé.
--project-id <N>Vérifie le quota/la signature d'un projet existant.
--deepRésout en plus l'arbre de dépendances npm (plafonné ~90 s).
Code de sortie
0 = le build devrait passer · 1 = bloqué (une ligne [FAIL] explique pourquoi). Parfait dans un script CI en garde-fou avant un vrai build.

Construire : upload, build, pull, run

Tout-en-un : run

Le plus simple : upload → build → pull en une commande, avec attente jusqu'à l'artefact téléchargé.

catalyst run ./my-app --target android --out app.apk
# zippe le dossier, crée le projet, lance le build APK,
# suit la progression et télécharge l'artefact dans app.apk

Étape par étape

# 1. Envoyer le code (crée un projet, ou --project-id pour rafraîchir)
catalyst upload ./my-app --name my-app          # → project_id=42

# 2. Lancer un build pour ce projet
catalyst build 42 --target ios --signing-mode unsigned   # → build_id=99

# 3. Suivre le build et récupérer l'artefact
catalyst pull 99 --out my-app.ipa

Cibles & signature — on choisit tout

Chaque commande de build accepte --target (web, iOS/.ipa, Android/.apk) et --signing-mode (signé / non signé). Le framework a une cible par défaut, mais vous pouvez toujours forcer l'autre (ex. un projet Expo par défaut en IPA, mais vous voulez un APK) :

catalyst build 42 --target android --signing-mode signed   # APK signé
catalyst build 42 --target ios     --signing-mode unsigned # IPA non signé
catalyst build 42 --target web                             # build web

Où tourne le build : --mode

--modeMoteurQuand l'utiliser
actionsCatalyst Actions (cloud managé)Par défaut fiable pour toutes les cibles (web, APK, IPA).
localFlotte de runners CatalystSi des runners dédiés sont configurés ; repli automatique sur le cloud sinon.

Référence des commandes

CommandeRôleOptions
loginSe connecter (navigateur)--no-browser · --token · --api
logoutSe déconnecter (révoque le jeton)--keep-token
whoamiAfficher le compte connecté
check <dir>Préflight : build OK ou bloqué (< 2 min)--target · --signing-mode · --project-id · --deep
upload <dir>Envoyer un dossier (crée/rafraîchit un projet)--project-id · --name · --framework · --organization
build <project_id>Lancer un build--mode · --branch · --target · --signing-mode
pull <build_id>Suivre un build et télécharger l'artefact--out · --no-watch
run <dir>upload → build → pull en une fois(toutes les options ci-dessus)
Toutes les commandes de la CLI Catalyst et leurs options principales.
Option globaleRôle
--api <url>Base de l'API (ou $CATALYST_API ; défaut : prod).
--token <pat>Jeton personnel (ou $CATALYST_TOKEN ; défaut : session stockée).
--versionAffiche la version de la CLI.
--helpAffiche l'aide et la liste des commandes.
Options globales, valables sur toutes les commandes.

Utilisation en CI/CD

En pipeline, pas de navigateur : fournissez le jeton via une variable d'environnement (créée dans Settings → API keys) et enchaînez check + run de façon non interactive.

export CATALYST_TOKEN="cat_xxxxxxxx_yyyyyyyyyyyyyyyy"

# Garde-fou : échoue le job si le build serait bloqué
catalyst check ./app --target android || exit 1

# Build + récupération de l'APK signé
catalyst run ./app --target android --signing-mode signed --out app.apk
Sécurité du jeton
Un PAT vaut un mot de passe : stockez-le dans les secrets de votre CI, jamais en clair dans le dépôt. Révoquez-le à tout moment avec catalyst logout ou dans Settings → API keys.