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-cliVia pip (Python ≥ 3.8) :
pip install catalyst-cliVérifiez l'installation :
catalyst --version
catalyst --helpConnexion : 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 login127.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| Option | Effet |
|---|---|
--no-browser | N'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é serveurSession, priorité & configuration
Pour chaque commande, l'API et le jeton sont résolus dans cet ordre (le premier trouvé gagne) :
| Priorité | Source | Exemple |
|---|---|---|
| 1 | Option de commande | --token cat_… / --api … |
| 2 | Variable d'environnement | CATALYST_TOKEN / CATALYST_API |
| 3 | Session stockée par login | ~/.catalyst/config.json |
| 4 | Valeur par défaut (prod) | aucune configuration requise |
| Variable | Rôle |
|---|---|
CATALYST_TOKEN | Jeton personnel (PAT) à utiliser. |
CATALYST_API | Base de l'API (ex. instance self-hosted). |
CATALYST_APP_URL | URL du site à ouvrir au login (si distincte de l'API). |
CATALYST_CONFIG_DIR | Dossier de la session (défaut : ~/.catalyst). |
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).| Option | Effet |
|---|---|
--target web|ios|android | Cible à vérifier (défaut : cible par défaut du framework). |
--signing-mode unsigned|signed | Vé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. |
--deep | Résout en plus l'arbre de dépendances npm (plafonné ~90 s). |
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.ipaCibles & 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 webOù tourne le build : --mode
| --mode | Moteur | Quand l'utiliser |
|---|---|---|
actions | Catalyst Actions (cloud managé) | Par défaut fiable pour toutes les cibles (web, APK, IPA). |
local | Flotte de runners Catalyst | Si des runners dédiés sont configurés ; repli automatique sur le cloud sinon. |
Référence des commandes
| Commande | Rôle | Options |
|---|---|---|
login | Se connecter (navigateur) | --no-browser · --token · --api |
logout | Se déconnecter (révoque le jeton) | --keep-token |
whoami | Afficher 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) |
| Option globale | Rô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). |
--version | Affiche la version de la CLI. |
--help | Affiche l'aide et la liste des 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.apkcatalyst logout ou dans Settings → API keys.