-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test DIY install.sh script #3015
base: alpha
Are you sure you want to change the base?
Conversation
apt-get -y install software-properties-common | ||
apt-get update | ||
apt_install software-properties-common | ||
apt-get --quiet update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ça poserait un problème de remonter cette ligne au-dessus du premier "install" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oui il me semble que software-properties-common
rajoute des sources et donc il faut refaire un update après
echo "${GREEN}Step 5 - php done${NORMAL}" | ||
} | ||
|
||
step_6_jeedom_download() { | ||
echo "---------------------------------------------------------------------" | ||
echo "${YELLOW}Starting step 6 - download Jeedom${NORMAL}" | ||
wget https://codeload.github.com/jeedom/core/zip/refs/heads/${VERSION} -O /tmp/jeedom.zip | ||
wget -nv https://codeload.github.com/jeedom/core/zip/refs/heads/${VERSION} -O /tmp/jeedom.zip |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wget --no-verbose
rm -rf ${WEBSERVER_HOME} && mkdir -p ${WEBSERVER_HOME} | ||
cd . | ||
mv -v -T /root/core-${VERSION} ${WEBSERVER_HOME} | ||
find ${WEBSERVER_HOME}/ -exec touch {} + # why ?? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sans être certain, peut-être pour mettre à jour la date des fichiers à « maintenant ». En tout cas c’est à ça que c’est censé servir.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, mais pourquoi vouloir modifier la date de tous les fichiers à la date / heure de l'installation? On a déjà un log pour ça... J'imagine que ça peut être utile pour démystifier un problème d'install ?
rm -rf /root/core-* > /dev/null 2>&1 | ||
rm -rf ${WEBSERVER_HOME}/core-* > /dev/null 2>&1 | ||
rm -rf ${WEBSERVER_HOME}/core-* > /dev/null 2>&1 # why ?? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surement à supprimer. Probablement un reste d’une ancienne méthode.
@@ -305,7 +307,7 @@ step_9_jeedom_configuration() { | |||
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 "DROP USER IF EXISTS 'jeedom'@'localhost';" | |||
mariadb_sql "CREATE USER 'jeedom'@'localhost' IDENTIFIED BY '${MARIADB_JEEDOM_PASSWD}';" | |||
mariadb_sql "DROP DATABASE IF EXISTS jeedom;" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On pourrait en profiter pour passer le nom de la DB en variable ?
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:Sur la matrice je n'ai laissé qu'une seule valeur par variable:
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