Add .env file for database configuration

[kwizer15]

Déplace la configuration de la base de donnée dans un fichier .env (surchargeable par .env.local).

Description

Cette PR est rétrocompatible, on priorise le nouveau système mais accepte le fichier /core/config/common.config.php en renvoyant une deprecated si le fichier .env est absent ou ne contient pas la configuration base de donnée.

Le fichier .env peut contenir 2 variables d’environnement :

DEBUG=0
DATABASE_DSN=mysql://user:password@localhost:3306/database_name

en pratique le fichier généré par l’installation sera le suivant

DATABASE_DSN=mysql://jeedom:password@localhost:3306/jeedom

(La génération du fichier partie peut être retirée de la PR si besoin, cela n'aura aucune conséquence.

• Cela simplifie grandement la génération du fichier de configuration.
• On peut facilement rajouter d'autres variables utiles (ici on gère DEBUG) sans casser ou regénérer quoi que ce soit.
• On peut imaginer gérer et prendre en charge directement les variables d'environnements du serveur (variables $_ENV, $_SERVER) afin de surcharger le fichier .env.

Suggested changelog entry

Move database configuration in /.env file.

Types of changes

• Bug fix (non-breaking change which fixes)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the [La ligne directrice pour contribuer à ce projet / Contribution guidelines for this project).
• I grant the project the right to include and distribute the code under the GNU.
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added MD documentation for the sniff.

[zoic21]

Bonjour,
Je comprends pas trop le but la ? Et j'avoue que les dernier PR sur la partie docker ont a chaque fois tout cassé...

[kwizer15]

Le .env est un standard.
Ca permet de surcharger ta config facilement si tu veux avoir plusieurs bdd par exemple. C'est dispo a la racine et pas au milieu du code.
La PR ne casse strictement rien pour l'existant.
L'idée dernière c'est de pour faire un environnement de test auto (qui sont laissé a l'abandon).
Le seul moyen d'avoir une appli sans trop de regression ce sont les tests, mais je veux pas faire péter les bases de dev a chaque lancement.
Voili voilou...

[zoic21]

Je vois pas trop l'interet on peut deja passer tout le parametrage en variable. C'est d'ailleurs ce qu'on fait nous chez jeedom pour tester le core.

[kwizer15]

Pardon mais j’ai du mal a comprendre ta réponse. Je parle d’avoir un environnement de dev dans lequel on peut lancer les tests phpunit en utilisant un bdd différente que celle du dev.

D’ailleurs si c’est possible, ça serait intéressant de documenter comment vous faites vos environnements de dev parce que la gestion des droits sur les fichiers est ingérable chez moi.

[zoic21]

Actuellement on a une action github pour le core qui s'occupe de checker que tout va bien en buildant le docker et en lancer le sick.php. C'est très léger mais ca suffit en général.

Pour les plugins il n'y a rien si ce n'est une validation de la syntaxe.

Après oui il y aurait un gros boulot pour mettre des vrais tests c'est sur mais malheureusement on a pas les moyens humain.

Pour ta modification je suis mitigé je vois pas le but au final. C'est pour changer de BDD en changeant juste un fichier .env ?

[kwizer15]

La configuration de base de donnée est une configuration d’environnement. Ce fichier permet de définir les variables d’environnement de ton application.
L’idée est donc de remplacer le fichier de config original common.config.php par ce fichier .env.
On peut rajouter un fichier .env.local qui permet de surchargé le .env (par exemple si tu veux mettre le DEBUG à 1, sans modifier ta conf original qui reste dans .env)
Ce que j’ai prévu dans une prochaine PR, c’est de rajouter un fichier .env.test qui ne sera pris en compte QUE par phpunit (via une variable d’environnement forcée dans la config de phpunit).
Ça veut dire que quand tu lanceras les tests unitaire, tu n’auras strictement aucun impact sur ta bdd de dev.

Je te renvoi vers cet article https://www.armandphilippot.com/article/dotenv-variables-environnement si tu veux en savoir plus, mais c’est aujourd’hui plus que courament utilisé dans le dev, et pas que en PHP. C’est même directement pris en compte par docker-compose.

[edgd1er]

Je parlerais que de l'image docker.

Actuellement, le common.config.php est alimenté par les variables d'environnements, le docker compose quand il lit les variables d'environnements, les crée et les valorise dans le conteneur en execution. Ce qui permet justement de "brancher" le conteneur docker si differentes BDD, pour tester par exemple.

Donc concernant l'image docker que les infos viennent du .env ou de la configuration de lancement de l'image c'est la meme.
La confusion pourrait arriver si, lors du build, en copiant/clonant le jeedom/core dans l'image docker un fichier .env existe dans le projet, et que le php lise en priorirté ce .env et non plus les variables d'environnement. Pour éviter cet écueil, il est possible d'aller réécrire le .env comme le commong.config.php est réécrit lors de l'execution du init.sh.

[kwizer15]

Actuellement, le common.config.php est alimenté par les variables d'environnements, le docker compose quand il lit les variables d'environnements, les crée et les valorise dans le conteneur en execution. Ce qui permet justement de "brancher" le conteneur docker si differentes BDD, pour tester par exemple.

Le build crée le fichier common.config.php avec des paramèters par défaut et un mot de passe généré aléatoirement (il en est de même pour le moment avec le .env sur ma PR). Ça ne permet pas de modifier ces variables à la volée sans rebuild l’image, seulement en modifiant le fichier.
Si vous parlez bien des variables suivantes de l’image docker

ENV DB_USERNAME=jeedom
ENV DB_NAME=jeedom
ENV DB_PORT=3306
ENV DB_HOST=localhost

Je ne les ai vu utilisée à aucun endroit. Ni dans le common.config.(sample.).php, ni dans l’install.sh. Si j’ai manqué quelque chose, je veux bien les infos.

La confusion pourrait arriver si, lors du build, en copiant/clonant le jeedom/core dans l'image docker un fichier .env existe dans le projet, et que le php lise en priorirté ce .env et non plus les variables d'environnement. Pour éviter cet écueil, il est possible d'aller réécrire le .env comme le commong.config.php est réécrit lors de l'execution du init.sh.

C’est ce qui est fait (en tout cas j’ai gardé le même comportement par soucis de rétrocompatibilité) et actuellement les 2 fichiers co-existent, le commong.config.php reprenant la main en cas de suppression du .env

[edgd1er]

Désolé, je fais court: le init.sh de l'image prend en charge la valorisation du fichier de conf bdd lors du lancement.

core/install/OS_specific/Docker/init.sh

Lines 98 to 103 in 685b1e3

	cp ${WEBSERVER_HOME}/core/config/common.config.sample.php ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#PASSWORD#/${MYSQL_JEEDOM_PASSWD}/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#DBNAME#/jeedom/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#USERNAME#/jeedom/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#PORT#/3306/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#HOST#/localhost/g" ${WEBSERVER_HOME}/core/config/common.config.php

Avec une erreur pour le mot de passe dans la master , mais avec une PR deja envoyé pour corriger l'ano: fix #

[kwizer15]

Désolé, je fais court: le init.sh de l'image prend en charge la valorisation du fichier de conf bdd lors du lancement.

core/install/OS_specific/Docker/init.sh

Lines 98 to 103 in 685b1e3

	cp ${WEBSERVER_HOME}/core/config/common.config.sample.php ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#PASSWORD#/${MYSQL_JEEDOM_PASSWD}/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#DBNAME#/jeedom/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#USERNAME#/jeedom/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#PORT#/3306/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#HOST#/localhost/g" ${WEBSERVER_HOME}/core/config/common.config.php

Avec une erreur pour le mot de passe dans la master , mais avec une PR deja envoyé pour corriger l'ano: fix #

On est d’accord que a part le mot de passe (préalablement généré), toute la config est en dur ?

[edgd1er]

On est d’accord que a part le mot de passe (préalablement généré), toute la config est en dur ?

le common.config.php.sample contient des valeurs en dur qui sont changées par les sed pour obtenir un fichier de configuration. common.config.php
l'image docker est un cas particulier puisque lors du lancement, il faut s'assurer que le fichier de config soit correctement valorisé a chaque lancement donc le init.sh recré le fichier common.config.php.

Dans le cas du bare-metal ou vm, l'étape 9 de l'installation (install.sh) prend en charge la valorisation du fichier commong.config.php: step_9_jeedom_configuration :

core/install/install.sh

Lines 302 to 323 in 5de9f9c

	step_9_jeedom_configuration() {
	echo "---------------------------------------------------------------------"
	echo "${YELLOW}Starting step 9 - Jeedom configuration${NORMAL}"
	if [ "${INSTALLATION_TYPE}" != "docker" ];then
	echo "DROP USER 'jeedom'@'localhost';" | mariadb -uroot > /dev/null 2>&1
	mariadb_sql "CREATE USER 'jeedom'@'localhost' IDENTIFIED BY '${MARIADB_JEEDOM_PASSWD}';"
	mariadb_sql "DROP DATABASE IF EXISTS jeedom;"
	mariadb_sql "CREATE DATABASE jeedom;"
	mariadb_sql "GRANT ALL PRIVILEGES ON jeedom.* TO 'jeedom'@'localhost';"
	cp ${WEBSERVER_HOME}/core/config/common.config.sample.php ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#PASSWORD#/${MARIADB_JEEDOM_PASSWD}/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#DBNAME#/jeedom/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#USERNAME#/jeedom/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#PORT#/3306/g" ${WEBSERVER_HOME}/core/config/common.config.php
	sed -i "s/#HOST#/localhost/g" ${WEBSERVER_HOME}/core/config/common.config.php
	fi
	chmod 775 -R ${WEBSERVER_HOME}
	chown -R www-data:www-data ${WEBSERVER_HOME}
	echo "${GREEN}Step 9 - Jeedom configuration done${NORMAL}"
	}

Cependant, Je comprends le besoin simple de lancer des tests via des BDD de tests avec des jeux de tests différentiés et si le .env aide, cela va dans le bon sens.
il faut s'assurer que cela ne vienne pas interférer avec les mécanismes existants d'installation ou de dockerisation. :)

[kwizer15]

@zoic21 est-ce que ce qui te gène c'est juste la partie docker (que je peux supprimer ca n'aura pas d'impact) ou la MR en général ?

[zoic21]

J'ai juste pas encore eu le temps de tester, la charge est assez importante en ce moment et docker est vraiment critique (plus qu'un bug dans le core) donc je dois passer des heures a tester les moindres changements sur docker.

[kwizer15]

Si ca peut te faire gagner du temps je peux virer la partie docker sans problème, c'était juste pour être plus clean. Je le répète, le common.config.php est toujours pris en compte tant qu'on surcharge pas avec un .env . J'ai bien fais attention a ne jamais rien casser pendant mon dev.

[zoic21]

Faut juste je test ton PR je peux pas le passer comme ca et la je suis complètement sous l'eau donc pas avant plusieurs semaines malheureusement, j'ai pris trop de truc dernièrement et je m'en sors plus.

[pifou25]

Pardon mais j’ai du mal a comprendre ta réponse. Je parle d’avoir un environnement de dev dans lequel on peut lancer les tests phpunit en utilisant un bdd différente que celle du dev.

D’ailleurs si c’est possible, ça serait intéressant de documenter comment vous faites vos environnements de dev parce que la gestion des droits sur les fichiers est ingérable chez moi.

J'utilise déjà un fichier .env et un docker-compose.yml et c'est suffisant pour avoir autant d'environnements que nécessaire en effet :) de ce que je comprends, ta PR vise à faire la même chose sans docker ? avoir 1 seule instance jeedom installée en local et plusieurs fichiers .env.* pour utiliser plusieurs bdd différentes que tu veux changer à la volée ?

Il ne faut pas faire ça : déjà, tu conserve la même version du code, donc tu ne pourra pas switcher d'une instance prod / master à une autre pour le dev / branche alpha, par exemple. Le code sera le même et les plugins installés aussi... sans parler des packages installés, version debian & co...
Pas le choix, il te faut installer docker, ou bien avoir plusieurs machines / plusieurs VM ... J'ai fait ce tuto pour utiliser Docker Desktop + Visual Studio Code sous Windows :
https://community.jeedom.com/t/tuto-dev-et-debug-de-jeedom-sous-windows-avec-vscode-et-docker/80751
Tu peux aussi utiliser Visual Studio Code avec une instance Docker distante.

Il faudrait juste un fichier .env et un docker-compose.yml pour l'exemple dans le repo.

[kwizer15]

Je me suis déjà fait mon environnement comme tu le dis. L'objectif est surtout d'apporter un peu de standard et d'éviter d'avoir une config qui traine au milieu des dossiers. Le .env n'est pas specifique a docker, et dans le cas de cette pr ca permet aussi d'avoir un environement sans docker et de lancer des tests auto sur une bdd indépendante.

C'est gentil pour le tuto mais je suis sous linux et vim.

[kwizer15]

@pifou25 En tout cas tout tuto est très bien fait, j'espère qu'il pourra servir a d'autres dev ;)

[pifou25]

vim comme IDE pour développer en php / js ? c'est un peu limité, tu ne dois pas avoir beaucoup d'aide (je ne connais pas vim mais j'imagine) En tout cas si tu es sous linux tu n'a aucune excuse, VS Code existe aussi !! et null besoin de Docker Desktop, tu n'a qu'à installer le docker client & démon en ligne de commande c'est suffisant, je devrais refaire un tuto identique pour linux en fait ^^

[kwizer15]

vim comme IDE pour développer en php / js ? c'est un peu limité, tu ne dois pas avoir beaucoup d'aide (je ne connais pas vim mais j'imagine)

Non, bien plus efficace que vscode, mais courbe d'apprentissage beaucoup plus longue.

En tout cas si tu es sous linux tu n'a aucune excuse, VS Code existe aussi !! et null besoin de Docker Desktop, tu n'a qu'à installer le docker client & démon en ligne de commande c'est suffisant, je devrais refaire un tuto identique pour linux en fait ^^

Rassure-toi je connais très bien tout ça, et ce n'est pas l'objectif de la PR.

[kwizer15]

@pifou25 si ca t'interesse, j'ai fais un dépot de mon environement.
https://github.com/kwizer15/jeedom-docker-env

Le principe c'est de pouvoir agir sur le code en local via un volume docker et de pouvoir cloner plusieurs versions en paralelle (je m'en sert pas vraiment en realité mais ca fonctionne).

Si ca peut te donner des idées pour ta PR.

[pifou25]

@kwizer15 Voila ma PR #2917 qui introduit un exemple de docker-compose.yml avec un fichier .env qui fait la même chose que cette PR.
On n'a pas besoin de modifier le code php comme tu le fais, et d'ailleurs ce n'est pas souhaitable par ailleurs. C'est vraiment sortir le rouleau compresseur pour écraser une mouche, c'est overkill! Ton repo justement répondrait très bien à ton besoin, pourquoi ne pas l'utiliser ?

[kwizer15]

@pifou25 Qu'as-tu compris exactement du but de ma PR ?
Tu me parles de docker mais ca n'a rien a voir avec au départ.

[pifou25]

@pifou25 Qu'as-tu compris exactement du but de ma PR ? Tu me parles de docker mais ca n'a rien a voir avec au départ.

Oui tout à fait, tu déplace la configuration de la bdd qui est dans le fichier config.common.php dans un fichier .env c'est limpide, Mais on n'a pas besoin de faire cela si on utilise docker, et c'est pour ça que j'en parle. Dans l'autre PR celle sur les phpunit, on utilise docker donc on n'en a pas besoin. Pour Jeedom non plus, en fonctionnement normal on n'en a pas besoin. Au final ça complexifie le core pour rien, pour un besoin qui t'es propre, mais tu devrais juste te mettre à docker :) Je ne doute pas que ça peut marcher (j'ai pas testé mais ça semble bien) mais si on peut éviter...
Après, je ne fais que donner mon avis, ce n'est pas moi qui décide d'accepter ou pas les PR.

[kwizer15]

Oui tout à fait, tu déplace la configuration de la bdd qui est dans le fichier config.common.php dans un fichier .env c'est limpide

On peut s’arrêter là, c’est juste l’objectif, mettre la config de base de donnée là où elle doit être, dans les variables d’environnements, rien de plus, rien de moins.

Mais on n'a pas besoin de faire cela si on utilise docker, et c'est pour ça que j'en parle.

Je suis d’accord, mais on sort du sujet

Dans l'autre PR celle sur les phpunit, on utilise docker donc on n'en a pas besoin.

Effectivement mais cette PR permet de le faire simplement. De plus, les tests sont censé pouvoir fonctionner indépendament de ton env de dev (quel qu’il soit). Et là sans cette PR (ou en tout cas sans modification de la conf bdd à la volée) ce n’est pas possible.

Pour Jeedom non plus, en fonctionnement normal on n'en a pas besoin.

Non, on n’en a pas besoin en «prod», comme la plupart des outils de dev, mais ca ne les empèche pas d’exister.

Au final ça complexifie le core pour rien

Y a rien de complexe là dedans, ca lit les différents .env, si y a rien on lit l’ancien config.common.php

Au final ça complexifie le core pour rien, pour un besoin qui t'es propre,

Je veux juste réduire les regression et simplifier un peut-être éventuel futur refacto en rajoutant des tests (j’ai déjà trouvé 2 bugs rien que dans la classe DB). Si tu as une autre solution qui fonctionne, je suis preneur.

mais tu devrais juste te mettre à docker :)

mais tu devrais juste te mettre à la modestie :)

[pifou25]

De plus, les tests sont censé pouvoir fonctionner indépendament de ton env de dev (quel qu’il soit)

C'est juste là que je ne suis pas d'accord, les tests ne sont censé passer que dans un env de test, et on ne devrait pas avoir à adapter le core pour faire passer nos tests.
Si tu ne veux pas utiliser docker, utilise des VM. Ou podman, ou tout autre outil de dev ou virtualisation ? Les alternatives ne manquent pas.

(edit)

Si tu as une autre solution qui fonctionne, je suis preneur.

Voici une solution simple qui n'affecte pas le core pour lancer tes phpunit en local, inspirée de l'install actuelle:

#!/usr/bin/env sh

WEBSERVER_HOME=${WEBSERVER_HOME:/var/www/html}

// configure specific database for test
set -a && source .env.local && set +a
cp ${WEBSERVER_HOME}/core/config/common.config.sample.php ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#PASSWORD#/${MYSQL_JEEDOM_PASSWD}/g" ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#DBNAME#/${MYSQL_JEEDOM_NAME}/g" ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#USERNAME#/${MYSQL_JEEDOM_USER}/g" ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#PORT#/${MYSQL_JEEDOM_PORT}/g" ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#HOST#/${MYSQL_JEEDOM_HOST}/g" ${WEBSERVER_HOME}/core/config/common.config.php

// run phpunit test
composer run-script test

// restore previous database from .env
set -a && source .env && set +a
cp ${WEBSERVER_HOME}/core/config/common.config.sample.php ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#PASSWORD#/${MYSQL_JEEDOM_PASSWD}/g" ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#DBNAME#/${MYSQL_JEEDOM_NAME}/g" ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#USERNAME#/${MYSQL_JEEDOM_USER}/g" ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#PORT#/${MYSQL_JEEDOM_PORT}/g" ${WEBSERVER_HOME}/core/config/common.config.php
sed -i "s/#HOST#/${MYSQL_JEEDOM_HOST}/g" ${WEBSERVER_HOME}/core/config/common.config.php

[kwizer15]

Oui on peux faire comme ça et surment de plein d'autres manières. Mais encore une fois, c'est hors-sujet.