Docker: custom "full" build

[XtraLarge]

Hello,

since version 14.1 a custom buld using the full example didn't work anymore. In the "full" example the CMD was changed from "apache-forground" to "/usr/bin/supervisord" so the installation or update process in the "/entrypoint.sh" script will never be triggered.
For my opinion the must be a third if clause so "supervisord" is also a trigger in the "/entrypoint.sh" script next "apache" and "php-fpm".

my solution is: (please be critical by checking it) file: [/entrypoint.sh]

#!/bin/bash
....
if [[ "$1" == *apache* ]] || [[ "$1" == *supervisord* ]] || [[ "$1" == *php-fpm* ]]; then

best regards
Willi

[J0WI]

Thanks for the hint, so we have to update our examples.
I would prefer using separate containers for cron and libreoffice instead of supervisord.

[SnowMB]

Great catch.

Modifying the entry point is not really practical because we can't add every other command that users want to use to it. I'm thinking adding an environment variable like FORCE_AUTO_INSTALL might work.

Cc @tilosp.

[tilosp]

Yes a variable makes sense.
I would call the var something like NEXTCLOUD_UPDATER, and you can set it to true or false. If it's not set we can use the already existing detection based on the command.
@SnowMB calling it AUTO_INSTALL is kind of misleading because it would also enable or disable the update script.

[SnowMB]

Sure. I just realized that the latest change might have broken the update for existing deployments (if they don't use apache-foreground or php-fpm) . That's really bad and should be fixed asap.

For the solution I am stuck here:

Introducing a variable and if it's
not present but the command is apache or php-fpm still doing updates is confusing.

Maybe relying on the environment variable and taking out the check would be clearer. It's also easier to document.

But on the other hand this would brake the update for all users. So not really an option.

Going the other way round and doing an opt out style would break the docker library echo test again.

We might have to move the checks for installed version and the used command around.

Any thoughts?

[tilosp]

Introducing a variable and if it's
not present but the command is apache or php-fpm still doing updates is confusing.

i don't think that it is that confusing. If you don't explicitly set it it simply tries to auto detect what you need.
And it can't break any additional setup because the behavior won't change without the new var.

Another benefit is that if your setup follows the one concern per container principle you don't have to set any additional vars. So it wouldn't confuse most users because they can simply ignore the var.
Only setup that ignore this principle have to set the new var.

[SnowMB]

@tilosp yeah I came to the conclusion that this might be the best solution after all. If nobody beats me to it I'll try to fix this this weekend.

[benwaffle]

Even if we use the environment variable, it would be nice to support supervisord in the entrypoint script as that is the recommended way to get cron running

[tilosp]

Even if we use the environment variable, it would be nice to support supervisord in the entrypoint script as that is the recommended way to get cron running

It's not the recommended way. The recommended way is to have a separate container for the cronjob.

[XtraLarge]

Hello,
You've forget to fix the "full" example. 
best regards ;)

[tilosp]

Hello, You've forget to fix the "full" example. best regards ;)

CC: @SnowMB

[SnowMB]

Oooops. Haha. Will do tomorrow. Or if you want to step in... :wink: