Add project-specific startup script support (eg. for cron configuration)

[martin-rueegg]

Allow user to add *.sh files to $HOST_PATH_HTTPD_DATADIR/*/.devilbox/autostart which will then be executed on startup of the php container.

[cytopia]

@martin-rueegg

This image already allows for adding "custom" scripts, but adding them hard-coded would not work as expected (see specific comment).

As an alternative, which would make more sense and is more flexible, I would add this directly into the Devilbox as an example script. Similar to what has been done here in the autostart/ dir for blackfire and nodejs:

https://github.com/cytopia/devilbox/tree/master/autostart

[cytopia]

The PHP-FPM images are not aware about the .devilbox/ directory. This is specific to the HTTPD images and can also be changed to any other directory:

https://github.com/devilbox/docker-nginx-mainline/blob/master/doc/environment-variables.md#-mass_vhost_template_dir

So hardcoding it here would not work.

In other words, the PHP-FPM images don't know about this path and hardcoding it here would result in it not working, once you change it via the HTTPD images (or in our use-case vie the Devilbox .env variable)

[martin-rueegg]

I see.

Would it be an option to propagate the MASS_VHOST_TEMPLATE_DIR to the PHP-FPM images too and use it in the script? Or create a new variable that defaults to the same directory?

[cytopia]

Would it be an option to propagate the MASS_VHOST_TEMPLATE_DIR

This would not make much sense, as the PHP images have nothing to do with it.

[martin-rueegg]

@cytopia Actually, You are already populating the MASS_VHOST_TEMPLATE_DIR to the php image in the form of HTTPD_TEMPLATE_DIR and you're even using it yourself in your code for the status page.

I have updated the code in order to use the value of that variable.

[martin-rueegg]

As an alternative, which would make more sense and is more flexible, I would add this directly into the Devilbox as an example script. Similar to what has been done here in the autostart/ dir for blackfire and nodejs:

https://github.com/cytopia/devilbox/tree/master/autostart

The disadvantage of the global autostart directory is that it is not project-specific and hence not distributed with the project code (e.g. via version control). It requires every developer working on the project to run additional installation steps for the project.

[cytopia]

As an alternative, which would make more sense and is more flexible, I would add this directly into the Devilbox as an example script. Similar to what has been done here in the autostart/ dir for blackfire and nodejs:
https://github.com/cytopia/devilbox/tree/master/autostart

The disadvantage of the global autostart directory is that it is not project-specific and hence not distributed with the project code (e.g. via version control). It requires every developer working on the project to run additional installation steps for the project.

The global autostart (all versions or per version) offers exactly this functionality. You can add any kind of shell script. It is just a generic way to start things up. What you do with it is totally up to the user.

What I can think of, is to add some generic template scripts *-example or add this to the documentation.

[martin-rueegg]

As an alternative, which would make more sense and is more flexible, I would add this directly into the Devilbox as an example script. Similar to what has been done here in the autostart/ dir for blackfire and nodejs:
https://github.com/cytopia/devilbox/tree/master/autostart

The disadvantage of the global autostart directory is that it is not project-specific and hence not distributed with the project code (e.g. via version control). It requires every developer working on the project to run additional installation steps for the project.

The global autostart (all versions or per version) offers exactly this functionality. You can add any kind of shell script. It is just a generic way to start things up. What you do with it is totally up to the user.

What I can think of, is to add some generic template scripts *-example or add this to the documentation.

It would still require to deploy the autostart script.

With the updated version of the code, the vHost config dir MASS_VHOST_TEMPLATE_DIR /HTTPD_TEMPLATE_DIR is used.

Does that make it better suitable or are you against any built-in support for this (as opposed to the global autostart scripts?