test DIY install.sh script

[pifou25]

Description

Cette PR est un exemple pour tester le script d'installation. Et tester les matrices d'exécution. Et aussi les runners auto-hébergés!

Le workflow ne teste principalement que le script install.sh j'ai donc filtré son exécution sur ce changement, toute autre modification sur du code php / js / autre ne justifie pas de déclencher ce workflow:

    paths:
      - install/**

Sur la matrice je n'ai laissé qu'une seule valeur par variable:

      matrix:
        debian: [ bullseye] # [bullseye, bookworm ]
        targetRunner: [ ubuntu-latest]  # [ ubuntu-latest, ARM, ARM64]
        database: [ 1] # [1, 0]

Mais le principe est que le workflow teste toutes les combinaisons.
Si vous mettez 2 versions Debian, 3 runners cible, et 2 param pour database, ça exécutera donc 2x3x2 = 12 tests. Toutes les combinaisons!

Et enfin, les runners auto-hébergé: Vous pouvez installer le nécessaire en qq lignes de script pour qu'une box devienne un runner github et exécute ce workflow! A titre d'exemple je l'ai testé chez moi sur un rpi2 et un rpi4 (en plus du runner github par défaut ubuntu-latest), et ça installe vraiment Jeedom sur le runner. Ce n'est pas dans un environnement virtualisé, à la fin du workflow je peux vraiment démarrer Jeedom sur l'appareil.
Vous pourrez dédier quelques box (luna atlas & co, avec différentes versions de debian, ou autre matériel plus personnalisable) pour vérifier l'installation automatique.
https://docs.github.com/fr/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
Mais, pour ce genre de workflow Github préconise de les lancer dans un repo privé, par sécurité:
https://docs.github.com/fr/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security

J'ai fait quelques modifs cosmétique dans install.sh (verbosité, syntaxe) c'est juste pour l'exemple, pour déclencher le workflow

[Mips2648]

Je propose de mettre bookworm directement dans la liste, pas de raison de ne pas tester sous bookworm

[pifou25]

Oui alors, comme je disais, ici c'est un exemple mais ça tourne sur un runner github ubuntu dans tous les cas. Ce libellé n'influe pas sur l'OS, github ne propose que des runners windows / mac / ubuntu... Par contre je l'ai testé avec des runner perso auto hébergés (rpi2 ou 3) sur lesquels j'ai installé le service ad-hoc pour écouter et exécuter ces jobs avec cette syntaxe:
targetRunner: [ ubuntu-latest, ARM, ARM64]
J'imagine qu'on peut faire cela avec des box (luna atlas smart ... autre matos) qui serait déjà installée avec chaque version de Debian pour multiplier les tests.

Ou sinon j'imaginais lancer le workflow à l'intérieur d'un container docker debian et dans ce cas oui , peut importe le runner github, on sera bien dans un OS debian au choix bullseye ou bookworm.

[Mips2648]

Quel est le but alors? et qu'est-ce que ce WF apporte concrètement? (si c'est juste pour montrer qu'on peut avoir des runners perso ... ok perso je savais... et puis?)
Tout en gardant à l'esprit qu'il y a déjà celui-ci: https://github.com/jeedom/core/blob/alpha/.github/workflows/docker-test.yml

Il faudrait définir l'objectif et surtout avoir une première version avec p-e moins d'options mais qui apporte déjà qlqch (tester sous ubuntu n'est pas vmt intéressant selon moi)

[pifou25]

Quel est le but c'est une bonne question :) je voulais surtout tester le script d'installation install.sh dans son intégralité. L'autre docker-test.yml teste l'image docker dont la construction est sensiblement différente, on utilise certaines fonctions du ìnstall.shmais pas toutes, et pas avec les mêmes paramètres (en particulier le type d'installation-i docker`).

Du coup je proposais de passer ce WF sur des runners perso correspondant au matériel habituellement utilisé. Et oui je ne connaissais pas les runners perso, j'ai découvert ça et je voulais le partager. Mais je suppose que jeedom fait déjà l'équivalent avec Jenkins (il me semble avoir vu qqpart qu'ils utilisent jenkins).

Autre option, j'ai modifié le WF pour jouer le script dans un container docker, avec les 2 versions debian. Ce n'est pas le Dockerfile cible, j'ai fait un Dockerfile spécifique qui exécute uniquement le script install.sh.