Skip to content
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

Open
wants to merge 1 commit into
base: alpha
Choose a base branch
from

Conversation

pifou25
Copy link
Contributor

@pifou25 pifou25 commented Jan 19, 2025

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

apt-get -y install software-properties-common
apt-get update
apt_install software-properties-common
apt-get --quiet update
Copy link
Contributor

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" ?

Copy link
Contributor Author

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
Copy link
Contributor

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 ??
Copy link
Contributor

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.

Copy link
Contributor Author

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 ??
Copy link
Contributor

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;"
Copy link
Contributor

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants