Développement

Utiliser ExpressJS avec Electron (Partie 2)

Dans cette seconde partie, nous allons voir comment compiler notre application et automatiser cette compilation via les Gitlab CI.

Ce tutoriel ne concerne que la compilation pour Windows, pour les autres configurations, vous pouvez lire la documentation officielle.

Installation

Pour pouvoir compiler notre application, nous allons utiliser le paquet NPM electron-builder. Pour cela, entrez simplement la commande suivante :

npm install -g electron-builder

Mise en place dans le projet

Dans un premier temps, créez un dossier builders. Ce dossier contiendra tous les fichiers de configuration pour la compilation de notre projet. Ajoutez dans ce dossier un premier fichier nommé electron-builder-dev.json. Dans ce fichier, nous renseignons les informations de compilation pour l’environnement de développement, avec notamment un ID d’application et un nom d’exécutable :

{
    "appId": "fr.test.electron",
    "artifactName": "${productName} - ${version} - COMMIT-TAG.${ext}",
    "win": {
        "target": [{
            "target": "portable",
            "arch": [
                "x64"
            ]
        }]
    }
}

Dans ce cas précis, j’ai ajouté « COMMIT-TAG » dans le champ « artifactName », nous y reviendrons plus tard.

Pour cet exemple, je n’ajoute que des options pour l’environnement Windows en précisant que je souhaites générer uniquement un projet portable pour l’architecture 64 bits.

IMPORTANT : Le système d’exploitation sur lequel vous compilez l’application générera un paquet Electron pour lui-même. Pour la cross-compilation, il est fortement recommandé d’utiliser Docker

Pour pouvoir utiliser cette configuration, il faut renseigner un nouveau script dans notre fichier package.json :

{
  // ...
  "scripts": {
    // ...
    "build-dev": "electron-builder -c ./builders/electron-builder-dev.json --win",
  },
  //...
}

Dans cette commande, l’option –win précise que l’on souhaite uniquement compiler l’application pour Windows. Libre à vous de laisser ou de retirer cette option. Vous trouverez plus d’informations du côté de la documentation officielle.

Vous pouvez essayer ce nouveau script en tapant dans votre terminal :

npm run build-dev

Après quelques secondes voire minutes, vous devriez voir un dossier un dossier « dist » contenant un sous dossier « win-unpacked » avec tous les fichiers ElectronJS décompilés, et un fichier exécutable (au format portable). Si vous exécutez ce fichier, votre application ElectronJS doit démarrer.

Tant que nous y sommes, nous allons faire de même pour la génération du projet en production :

Fichier electron-builder-prod.json :

{
  "appId": "fr.test.electron",
  "artifactName": "${productName} - ${version}.${ext}",
  "win": {
      "target": [{
          "target": "portable",
          "arch": [
              "x64"
          ]
      }]
  }
}

Fichier package.json :

{
  // ...
  "scripts": {
    // ...
    "build-prod": "electron-builder -c ./builders/electron-builder-prod.json --win"
  },
  // ...
}

La seule différence dans ce script est le nom final de la compilation.

Utilisation de Gitlab-CI

Pour la compilation automatique, nous disposons d’un Gitlab avec des runners installés.

Le gros avantage de la compilation automatique est que lorsque vous avez fini une fonctionnalité, vous pouvez vérifier automatiquement (et sans prendre de ressources sur votre ordinateur) si votre application peut toujours être compilée pour être distribuée aux utilisateurs.

Pour les activer sur notre projet, nous allons créer un fichier .gitlab-ci.yml et allons y entrer ceci :

image: node:8.14.0-alpine

before_script:
  - apk add --no-cache openrc
  - num install -g npm@latest
  - npm install
  - npm install -g electron-builder
  
stages:
  - test
  - artifact

unit-test:
  stage: test
  script:
    - npm run test

artifact-master:
  image: electronuserland/builder:wine
  stage: artifact
  only:
    - master
  script:
    - npm run build-prod
  artifacts:
    name: "$CI_PROJECT_NAME-CI_COMMIT_REF_NAME"
    paths:
      - "dist/*.exe"

artifact-development:
  image: electronuserland/builder:wine
  stage: artifact
  only:
    - develop
  script:
    - sed -i "s/COMMIT-TAG/${CI_COMMIT_SHA:0:8}-$CI_COMMIT_REF_SLUG/g" ./builders/electron-builder-dev.json
    - npm run build-dev
  artifacts:
    name: "$CI_PROJECT_NAME-CI_COMMIT_REF_NAME"
    paths:
      - "dist/*.exe"

Passons en détail ce fichier :

  • [before_script] Dans un premier temps, on s’assure que notre image Docker est bien à jour et on installe les dépendances;
  • [unit_test] Il s’agit d’une partie à mettre en place rapidement : les tests. Dans ce cas, on ne fait que lancer le script de tests
  • [artifact_master] Il s’agit ici de la compilation de l’application pour la production. Etant donné qu’on ne souhaite compiler que pour Windows, nous utilisons l’image Docker contenant tous les outils pour le faire. On lance ensuite notre script de génération en production puis on viens récupérer le fichier exécutable pour le rendre accessible à l’extérieur du container Docker.
  • [artifact_develop] Même principe que pour le script précédent, sauf qu’on utilise dans ce cas le script de compilation pour le développement. Si vous avez laissé l’expression « COMMIT-TAG » dans le fichier electron-builder-dev.json, Gitlab remplacera ce terme par l’identifiant du commit et le nom de la branche (dans notre cas, « develop » permet de savoir qu’on est effectivement sur une version développement de l’application)

Dans ce cas précis, nous lançons des tests-unitaires qui vont forcément échouer… Pour résoudre ce problème pour le moment, retournez dans votre fichier package.json et modifier le script de test :

{
  // ...
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 0",
    // ...
  },
  // ...
}

Cela permettra à Gitlab de terminer ses tests sur un code 0 (pas d’erreur).

Si vous poussez les modification, Gitlab exécutera :

  • Sur la branche « master », les tests et une compilation pour la production;
  • Sur la branche « develop », les tests et une compilation pour le développement;
  • Sur les autres branches, uniquement les tests;

Une fois les modifications poussées sur les branches « develop » ou « master », vous verrez apparaître un document zippé sur votre Gitlab. Vous pouvez alors télécharger cette archive et exécuter votre application.

Pour la distribution de votre application, il est très fortement conseillé de ne distribuer que l’exécutable généré sur la branche « master », car cette branche n’est censée ne contenir que le code stable.

1 Comment

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *