Automatically install apps specified via env variable. #29

Merged
decentral1se merged 3 commits from auto_app_install into main 2022-11-09 09:48:24 +00:00
Member

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.

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 added 1 commit 2022-11-08 11:58:15 +00:00
continuous-integration/drone/pr Build is failing Details
20f0a45baf
Automatically install apps specified via env variable.
Owner

@moritz Nice one, thanks for opening this up!

But unfortenatley abra.sh functions are executed using /bin/sh instead of bash, which complicates things.

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?

I created this PR, because I am not sure if this is the way to go, feels a bit hacky.

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 the exec 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.

@moritz Nice one, thanks for opening this up! > But unfortenatley abra.sh functions are executed using /bin/sh instead of bash, which complicates things. 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? > I created this PR, because I am not sure if this is the way to go, feels a bit hacky. 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 the `exec` 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.
moritz added 2 commits 2022-11-08 15:40:25 +00:00
Author
Member

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 the exec 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 on sub_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?

> 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 the `exec` 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 on `sub_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?
decentral1se merged commit 63ce9a6fb9 into main 2022-11-09 09:48:24 +00:00
Owner

Thanks @moritz!

To avoid any issues I changed the PR to be a abra.sh post-install command.

Solid, seems like a safe bet for now.

P.S. abra.sh contains many functions depending on sub_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?

From the days of an Elegant Weapon for a More Civilized Age

Thanks @moritz! > To avoid any issues I changed the PR to be a abra.sh post-install command. Solid, seems like a safe bet for now. > P.S. abra.sh contains many functions depending on sub_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? From the days of an [Elegant Weapon for a More Civilized Age](https://git.coopcloud.tech/coop-cloud/abra-bash)
Author
Member

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?

> From the days of an [Elegant Weapon for a More Civilized Age](https://git.coopcloud.tech/coop-cloud/abra-bash) 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?
Owner

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!

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!
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/nextcloud#29
No description provided.