Référence des scripts

Infos supplémentaires en bref - Pour référence en cas de besoin sur les scripts de développement pour des dépôts d’applications construits sur Pankosmia

Table des matières

Configuration de l’écosystème

Ce dépôt rassemble plusieurs bibliothèques et projets en une seule application. Les projets sont répartis sur plusieurs dépôts pour permettre une réutilisation modulaire. Des scripts suivent pour aider à la configuration, bien que tout puisse également être configuré manuellement. Ce qui suit suppose que les dépôts sont installés avec la structure de répertoires suivante.

Ceci est un exemple. Les clients utilisés peuvent varier. La configuration est gérée via app_config.env et le script app_setup.

|-- repos
    |-- pankosmia
        |-- core-client-content repository
        |-- core-client-dashboard repository
        |-- core-client-i18n-editor repository
        |-- core-client-remote-repos repository
        |-- core-client-settings repository
        |-- core-client-workspace repository
        |-- [your-desktop-app-repo-name] (30 characters or less on windows!)
        |-- resource-core
        |-- webfonts-core

Installation des clients

Le local_server (pankosmia_web) sert les fichiers compilés depuis le répertoire build de chaque client, donc chaque client doit être compilé.

Ceci est géré par les scripts clone et build_clients, bien que tout puisse également être exécuté manuellement, ce qui est utile pendant le développement.

# Dans chaque dépôt client, PAS dans ce dépôt !
npm ci
npm run build

L’exécution de run, build_server ou bundle_... copie la dernière version compilée vers l’environnement de build.

Scripts

Les scripts se trouvent dans <os>/scripts/ et doivent être exécutés depuis ce répertoire (par exemple, cd linux/scripts/, cd windows\scripts\, cd macos/scripts/). Les scripts échoueront s’ils sont exécutés depuis un autre emplacement. Extensions de fichiers par OS : Linux → .bsh, macOS → .zsh, Windows → .bat (sauf indication contraire). Les chemins utilisent / sur Linux/macOS et \ sur Windows. [1]

Configuration

Les fichiers de configuration doivent correspondre aux clients et assets utilisés. Des scripts pour les générer sont fournis, selon app_config.env. Les fichiers créés par le script app_setup sont :

  • buildSpec.json
  • /globalBuildResources/i18nPatch.json
  • /globalBuildResources/product.json
  • /<os>/buildResources/setup/app_setup.json

Vérifiez app_config.env et ajustez si nécessaire, puis exécutez l’un des scripts de configuration qui suivent. Relancez le script app_setup chaque fois que app_config.env est modifié.

Scripts de configuration :

Exécutez depuis l’emplacement indiqué :

Description Script et arguments
cd <os>/scripts/
Linux : `.bsh` | macOS : `.zsh` | Win : `.bat`
Utilise app_config.env pour générer/reconstruire/remplacer app_setup.json, buildSpec.json, product.json et i18nPatch.json app_setup

Scripts de configuration :

Exécutez depuis l’emplacement indiqué :

Description Script et arguments
cd <os>/scripts/
Linux : `.bsh` | macOS : `.zsh` | Win : `.bat`
Clone tous les dépôts dans /app_config.env si un répertoire portant ce nom n’existe pas déjà clone
  Clone par défaut via HTTPS.
Argument optionnel :
clone -s
  Clone via SSH.
Pour chaque dépôt d’assets dans /app_config.env : git checkout main, git pull
Pour chaque dépôt client dans /app_config.env : git checkout main, git pull, npm ci et npm run build.
Les développeurs doivent compiler manuellement lorsqu’ils testent des branches.
build_clients
Arguments optionnels :
build_clients [branch|dev|qa] [dev|qa]
  Lorsque « my-branch » n’existe pas, le repli sera « main » sauf si l’argument suivant est spécifié. Si « dev » est indiqué, un repli « dev » → « qa » → « main » est implicite. Si « qa » est indiqué, un repli « qa » → « main » est implicite.
build_clients -d
  Supprime les anciens logs sans demander.
build_clients -f
  Ignorer le pull car tous les dépôts sont des clones récents.
Créer une visionneuse Electronite à utiliser avec l’environnement de build de développement local. build_viewer
Windows : utilise .ps1 (utilisez un terminal PowerShell)

Scripts d’utilisation :

Note : Plusieurs arguments peuvent être appliqués dans n’importe quel ordre, par exemple build_server -s dev debug est identique à build_server debug dev -s

Description Script et arguments
cd <os>/scripts/
Linux : `.bsh` | macOS : `.zsh` | Win : `.bat`
Supprime le répertoire de build et exécute cargo clean [4] clean
Argument optionnel :
clean -s
  Ne demandera pas si le serveur est arrêté
Exécute cargo build et node build.js build_server
Arguments optionnels :
build_server dev
  Utilise la version « dev » dans /local_server.env
build_server qa
  Utilise la version « qa » dans /local_server.env
build_server -s
  Ne demandera pas si le serveur est arrêté
build_server [ critical | normal (défaut) | debug | off ]
  Réécrit le niveau de log dans Rocket.toml
Assemble l’environnement de build (clients) et démarre le serveur [2] run
Argument optionnel :
run -s
  Ne demandera pas si le serveur est arrêté
Lance la visionneuse Electronite pour l’utiliser avec l’environnement de développement. (Nécessite que la visionneuse ait été préalablement créée via le script build_viewer.) viewer
Outils de développement : Ctrl + Shift + I (macOS : Cmd + Option + I)
Argument optionnel :
viewer [PORT#]
(par défaut 19119)
Supprime les derniers bundles et le contenu temporaire pour le système d’exploitation donné (s’ils existent), puis sur ce dépôt exécute git checkout main, git pull et npm ci, exécute app_setup pour assurer la cohérence des versions, exécute node build.js, puis crée un bundle de release zip et un installateur autonome. (*) (•) bundle_viewer
Linux : Pas d’arguments optionnels. Ne compile et ne crée le bundle que pour la visionneuse. Faites tout le reste manuellement ou via d’autres scripts listés ici.
Windows : Utilise .ps1. Argument optionnel :
bundle_viewer.ps1 -ServerOff "Y"
  Ne demandera pas si le serveur est arrêté
macOS : Argument optionnel :
bundle_viewer -s
  Ne demandera pas si le serveur est arrêté
Supprime le dernier bundle de release s’il existe, puis sur ce dépôt exécute git checkout main, git pull et npm ci, exécute app_setup pour assurer la cohérence des versions, exécute node build.js, puis crée un bundle de release zip/tgz [2] Linux : bundle_tgz
Windows : bundle_zip.ps1
macOS : bundle_zip
Arguments optionnels :
Linux/macOS :
bundle_tgz -s / bundle_zip -s
  Ne demandera pas si le serveur est arrêté
bundle_tgz -g / bundle_zip -g
  Exécuter depuis GitHub Actions
Windows :
bundle_zip.ps1 -ServerOff "Y"
  ou : « y » ; Ne demandera pas si le serveur est arrêté
bundle_zip.ps1 -IsGHA "Y"
  ou : « y » ; Exécuter depuis GitHub Actions

Scripts de maintenance :

Exécutez depuis l’emplacement indiqué :

Description Script et arguments
cd <os>/scripts/
Linux : `.bsh` | macOS : `.zsh` | Win : `.bat`
Facilite la synchronisation avec l’upstream en excluant les fichiers susceptibles de différer : sync
Argument optionnel :
sync -p
  Ne demandera pas si la dernière version est déjà récupérée.

Notes de bas de page

[1] … Lors de l’exécution d’un script bat depuis une invite de commandes, le .\ inclus dans les exemples est facultatif.

[2] … Assurez-vous que le serveur local est à jour ! Il s’agit du script build_server, ou build_server dev ou build_server qa si /local_server.env contient des versions différentes de panksomia_web dans /local_server/Cargo.toml.

[3] … Prérequis d’environnement pour exécuter le build exe localement : Installez Inno Setup - testé avec la v6.4.3

[4] … Conseils de nettoyage ciblé :

  • Pour nettoyer uniquement le serveur local : allez dans le répertoire /local_server et exécutez cargo clean
  • Pour nettoyer uniquement l’environnement de build, allez dans le sous-répertoire de votre OS (c’est-à-dire /macos, /linux ou /windows), puis supprimez récursivement son sous-répertoire build.
  • (Le script clean fait tout ce qui précède.)