Closed saleyn closed 2 years ago
Is this just a ways to define the already supported pre/post hooks but instead of putting the pre/post definition in the relx config it is resolved from the name of the script?
Hehe, cat hit the keyboard when I was going to comment and hit the 'close and comment' buton.
Yes, I believe this approach is more transparent as the config way is a two-step process - you need to create the hook files, and then add them to the config, whereas this approach just uses the hooks files that the maintainer creates in the filesystem. It's very similar to the systemd's convention for service configuration files, shells (/etc/profile.d), and other software.
A new variation of the
extended_start_script_hooks
option is added that can define a source directory containing hook scripts:{directory, HookScriptsDir::string()}
. When defined, the scripts will be copied to a sub-folder in the release at the level of the extended start script. That subfolder will have the same name as the basename of the extended start script (without the release version number and extension), and will have a.d
suffix.That subdirectory can contain
pre-/post-
start/stop/install
scripts with by saving them in the startup script's release directory that has a.d
suffix. So, if the extended script's name ismyapp.sh
, then the hook directory can be:The hook extension files can have any suffix (such as
.NN
shown above). The files in this directory will be sourced only if the correspondingPRE_*
orPOST_*
variables (populated by respectivepre_*
andpost_*
hook configuration options) don't contain script names that override this behavior.