Je suis l’auteur de 2 nouvelles PR sur le code pour l’image Docker de Jeedom
La 1ère PR est un fix sur l’init.sh qui n’apparait que lorsqu’on lance le container Jeedom avec un partage sur /var/www/html … Le paramètre doit être 10
Pour la 2e c’est plus compliqué, c’est pour ça que je l’ai laissé en draft pour le moment : je voulais surtout corriger le fait que l’installation prend le script sur la branche alpha - en dur - au lieu d’utiliser la version de la branche en cours wget https://raw.githubusercontent.com/jeedom/core/alpha/install/install.sh -O /root/install.sh
J’ai donc rajouté la variable ${VERSION} Mais malgré cela, le workflow Github génère quand même les 2 images (v4-stable et alpha) avec le code Jeedom v4.3.x donc la stable. J’ai donc ajouté ce paramètre aussi sur le script d’install dans le Dockerfile: RUN sh /tmp/install.sh -v ${VERSION} -w ${WEBSERVER_HOME}
Logiquement ça marche, maintenant je me pose la question du workflow Github ; à priori c’est la branche v4-stable du workflow qui génère les 2 images, déclenché par un cron. Pourquoi ce choix, de grouper les 2 branches dans 1 seul workflow ? Et pourquoi le cron, plutôt qu’un déclenchement automatique à chaque merge sur cette branche (il n’y en a pas tous les jours en principe)(?)
Je proposerais plutôt que chaque branche génère sa propre image. Et d’ailleurs ça peut faire un prochain PR bref je suis dispo pour en discuter un peu.
Bonjour,
Merci pour tes PR. J’avoue ne pas etre assez competent pour savoir te répondre ou meme jugé si ils sont bon ou pas. Pour le 1er pas de soucis je vais l’accepter.
Pour le 2eme je l’accepterai quand il ne sera plus draft, c’est moi qui ait mis en place les workflow mais je comprends pas vraiment comment ca marche sur github donc c’est tombé en marche j’ai laissé comme ca.
Je n’ai retenu que 2 branches pour l’automatisation : V4-stable et beta, les 2 sont géré dans le même fichier avec les paramètres qui vont bien
Je prend le numéro de version dans core/config/version, sans le numéro de fix, donc la branche stable crée le tag jeedom:4.3 et la beta => jeedom:4.4
La branche V4-stable crée aussi le tag jeedom:latest et beta crée aussi le tag jeedom:beta
On pourrait aussi créer un tag pour chaque fix sur la stable, on aurait ainsi sur le Docker hub l’historique de toutes les releases 4.3.x conservées
J’ai laissé la possibilité de déclencher un build manuellement. ça permet par exemple de builder sur la branche alpha si on sélectionne cette branche, mais dans ce cas ça publie sur Docker hub un tag jeedom:4.4 avec le code alpha au lieu de beta
