Commande CI

npx intlayer ci <command...>

La commande CI est conçue pour l'automatisation et les pipelines CI/CD. Elle injecte automatiquement les identifiants à partir de la variable d'environnement INTLAYER_PROJECT_CREDENTIALS et peut exécuter des commandes Intlayer sur plusieurs projets dans un monorepo.

Fonctionnement

La commande CI fonctionne en deux modes :

1. Mode projet unique : Si le répertoire de travail actuel correspond à l'un des chemins de projet dans INTLAYER_PROJECT_CREDENTIALS, elle exécute la commande uniquement pour ce projet spécifique.

2. Mode itération : Si aucun contexte de projet spécifique n'est détecté, elle itère sur tous les projets configurés et exécute la commande pour chacun d'eux.

Variable d'environnement

La commande nécessite que la variable d'environnement INTLAYER_PROJECT_CREDENTIALS soit définie. Cette variable doit contenir un objet JSON mappant les chemins de projet à leurs identifiants :

{
  "packages/app": {
    "clientId": "your-client-id-1",
    "clientSecret": "your-client-secret-1"
  },
  "packages/admin": {
    "clientId": "your-client-id-2",
    "clientSecret": "your-client-secret-2"
  }
}

Détection du gestionnaire de paquets

La commande CI détecte automatiquement le gestionnaire de paquets utilisé (npm, yarn, pnpm ou bun) en fonction de la variable d'environnement npm_config_user_agent et utilise la commande appropriée pour exécuter Intlayer.

Arguments

• <command...> : La commande Intlayer à exécuter (par exemple, fill, push, build). Vous pouvez passer n'importe quelle commande Intlayer et ses arguments.

  Exemple : npx intlayer ci fill --verbose

  Exemple : npx intlayer ci push

  Exemple : npx intlayer ci build

Exemples

Exécuter une commande en mode projet unique

Si vous êtes dans un répertoire de projet qui correspond à l'un des chemins dans INTLAYER_PROJECT_CREDENTIALS :

cd packages/app
npx intlayer ci fill

Cela exécutera la commande fill avec les identifiants automatiquement injectés pour le projet packages/app.

Exécuter une commande sur tous les projets

Si vous êtes dans un répertoire qui ne correspond à aucun chemin de projet, la commande itérera sur tous les projets configurés :

cd /path/to/monorepo
npx intlayer ci push

Cela exécutera la commande push pour chaque projet configuré dans INTLAYER_PROJECT_CREDENTIALS.

Passer des drapeaux supplémentaires

Vous pouvez passer n'importe quels drapeaux à la commande Intlayer sous-jacente :

npx intlayer ci fill --verbose --mode complete

Utilisation dans les pipelines CI/CD

L'exécution de intlayer init crée deux workflows GitHub Actions prêts à l'emploi pour vous (voir Scaffolded GitHub Actions ci-dessous). L'exemple ici montre la configuration équivalente en utilisant la commande ci pour un monorepo, où les credentials sont injectés par projet depuis INTLAYER_PROJECT_CREDENTIALS.

Dans votre configuration CI/CD (par exemple, GitHub Actions, GitLab CI), définissez INTLAYER_PROJECT_CREDENTIALS comme secret :

# Exemple GitHub Actions
env:
  INTLAYER_PROJECT_CREDENTIALS: ${{ secrets.INTLAYER_PROJECT_CREDENTIALS }}

steps:
  - name: Remplir les dictionnaires
    run: npx intlayer ci fill

GitHub Actions générés automatiquement

Lorsque vous exécutez intlayer init, Intlayer détecte votre gestionnaire de paquets (npm, yarn, pnpm, ou bun) et génère automatiquement deux workflows GitHub Actions sous .github/workflows/, avec des commandes correspondant à ce gestionnaire de paquets :

• intlayer-fill.yml — Sur chaque pull request, construit les dictionnaires et exécute intlayer fill --git-diff --mode complete pour générer les traductions manquantes pour les dictionnaires modifiés, puis valide le résultat sur la branche PR.
• intlayer-test.yml — Sur chaque pull request, construit les dictionnaires et exécute intlayer test, échouant la vérification si les locales requises ont des traductions manquantes.

Les fichiers de workflow existants ne sont jamais écrasés. Pour ignorer complètement la génération automatique, exécutez :

npx intlayer init --no-github-actions

Fournir un accès IA au workflow de remplissage

Le fichier intlayer-fill.yml généré nécessite un accès IA. Deux options sont disponibles (configurées dans le bloc env du workflow) :

1. Votre propre clé de fournisseur IA — Ajoutez un secret AI_API_KEY dans les paramètres de votre référentiel (Settings → Secrets and variables → Actions). Le workflow le transmet via --provider, --model et --api-key.
2. Clés d'accès Intlayer CMS — Ajoutez les secrets INTLAYER_CLIENT_ID et INTLAYER_CLIENT_SECRET et intégrez-les dans la section editor de votre intlayer.config. Les clés d'accès CMS accordent l'accès IA via le backend Intlayer.

Le workflow intlayer-test.yml ne nécessite aucun accès IA.

Gestion des erreurs

• Si INTLAYER_PROJECT_CREDENTIALS n'est pas définie, la commande se terminera avec une erreur.
• Si INTLAYER_PROJECT_CREDENTIALS n'est pas un JSON valide, la commande se terminera avec une erreur.
• Si un chemin de projet n'existe pas, il sera ignoré avec un avertissement.
• Si un projet échoue, la commande se terminera avec un code de statut non nul.

Cas d'utilisation

• Automatisation de monorepo : Exécuter des commandes Intlayer sur plusieurs projets dans un monorepo
• Pipelines CI/CD : Automatiser la gestion des dictionnaires dans les workflows d'intégration continue
• Opérations en masse : Effectuer la même opération sur plusieurs projets Intlayer à la fois
• Gestion des secrets : Gérer de manière sécurisée les identifiants pour plusieurs projets en utilisant des variables d'environnement

Bonnes pratiques de sécurité

• Stockez INTLAYER_PROJECT_CREDENTIALS comme secrets chiffrés dans votre plateforme CI/CD
• Ne commitez jamais les identifiants dans le contrôle de version
• Utilisez des identifiants spécifiques à l'environnement pour différents environnements de déploiement
• Faites tourner les identifiants régulièrement