Automatically install apps specified via env variable. #29
Loading…
Reference in New Issue
No description provided.
Delete Branch "auto_app_install"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Nextcloud Apps specified in the env variable
APPS
will be installed automaticially by the entrypoint.sh script.In case nextcloud isn't already installed the originaly entrypoint.sh will be executed without running php-fpm to install nextcloud.
Only after a successfull installation the APPS will be installed.
I created this PR, because I am not sure if this is the way to go, feels a bit hacky.
Another way would be to use an abra.sh command. But unfortenatley abra.sh functions are executed using /bin/sh instead of bash, which complicates things. Further it is an additional step to run the post-deployment command using abra.sh.
A more general method would be to specify a list of occ commands via env variable, instead of the apps.
@moritz Nice one, thanks for opening this up!
We could try to generalise this to run with
/bin/bash
if it is present? I think/bin/sh
was chosen as the simple "always there" option but it doesn't quite help in this situation. You could open a ticket on the organising repo so we could follow this up?Yeh, I'm not sure also. The main question for me is, do your changes rely on the upstream entrypoint never changing? I think
sed
'ing theexec
is pretty safe? But then making a conditional about installing Nextcloud or not... is that safe?The worry is that the upstream entrypoint will change one day and our installer entrypoint will break in a probably very mysterious way for our future selves.
I prefer the extra effort of a manual
abra.sh
post-install step than potentially losing$n
hours debugging obscurities in the future 😅 Maybe one to ask for feedback in the Tech channel on matrix also!Let's see what the others say.
I think it should be "quite" robust, but as you said, you never know how the upstream entrypoint will change and using
abra.sh
is the cleaner way.To avoid any issues I changed the PR to be a
abra.sh
post-install command.This way the desired apps can be either specified in the env variable or directly on the command line.
P.S.
abra.sh
contains many functions depending onsub_app_run
, which is not defined (anymore?). Are any of these functions still in use or should this file maybe cleaned from old unused functions?Thanks @moritz!
Solid, seems like a safe bet for now.
From the days of an Elegant Weapon for a More Civilized Age
So, as its deprecated is it ok if I push a commit with a cleaned abra.sh, or should I simply leave it to avoid breaking things for people who still use the deprecated version?
Oh yes please @moritz! You're part of the https://git.coopcloud.tech/coop-cloud orga, so you have read/write permissions on all the repos and feel free to use it! It's nice to see a PR when something feels like it needs a discussion but otherwise, happy hacking and push away!