Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support sub-directories within docker-entrypoint-initdb.d #605

Closed
lloydpowell88 opened this issue Aug 13, 2019 · 4 comments
Closed

Support sub-directories within docker-entrypoint-initdb.d #605

lloydpowell88 opened this issue Aug 13, 2019 · 4 comments
Labels
Request Request for image modification or feature

Comments

@lloydpowell88
Copy link

As it stands, the docker-entrypoint-initdb.d folder will only run the scripts from it's root.

I have a scenario where it would be extremely tidy for it to run all scripts from directories placed in the root also (recursively would be nice too but probably not required).

This makes the managing of a multi-version application deployed in multiple environments much more simplistic. It allows us to group our scripts by folders making them more understandable, readable and easier to avoid the alphabetical ordering of all the scripts (this could be done by the grouping folders).

I can make this change easily enough myself and more than happy to create a pull request to see if others would find it beneficial also.

What do you think team?

@lloydpowell88
Copy link
Author

lloydpowell88 commented Aug 13, 2019

Pull Request if deemed appropriate - #606

@wglambert wglambert added the Request Request for image modification or feature label Aug 13, 2019
@yosifkit
Copy link
Member

Maybe we just recommend users mount a script and have it run other scripts in their folders.

Duplicate of #179

I think we are still hesitant to have such a possibly breaking change (even more now with the long precedent of the current behavior).

So the current script users need to create would be a copy lines 145-163 to get the same behavior.

for f in /docker-entrypoint-initdb.d/*; do
case "$f" in
*.sh)
# https://github.com/docker-library/postgres/issues/450#issuecomment-393167936
# https://github.com/docker-library/postgres/pull/452
if [ -x "$f" ]; then
echo "$0: running $f"
"$f"
else
echo "$0: sourcing $f"
. "$f"
fi
;;
*.sql) echo "$0: running $f"; "${psql[@]}" -f "$f"; echo ;;
*.sql.gz) echo "$0: running $f"; gunzip -c "$f" | "${psql[@]}"; echo ;;
*) echo "$0: ignoring $f" ;;
esac
echo
done

Hopefully #496 will be finished up soon and that should make it easier for the custom script. Once merged the script would be roughly one line of code.

#!/bin/bash
# script will need to not be executable (chmod -x) so that it gets sourced rather than executed
# that is the current behavior, but this function doesn't exist yet
docker_process_init_files /docker-entrypoint-initdb.d/*/*
# or something else to better control the order of script and sql processing

@lloydpowell88
Copy link
Author

lloydpowell88 commented Aug 14, 2019

Thanks for the response @yosifkit .

That's a shame, although breaking changes shouldn't always be considered a blocker from releasing a new feature. Especially in a case like this where people probably shouldn't really be putting folders in if they don't expect them to be used.

Maybe it could be reconsidered for the next major version :-), then those updating will know the potential of breaking changes when updating.

Thanks for sending through the potential alternative, I'll keep my eye on that change making it's way through.

@yosifkit
Copy link
Member

Closing since this is not something we want to add.

Since scripts initdb scripts can be sourced (#452) and everything in the script is functionalized (#496), a custom script in initdb can easily use the docker_process_init_files function to recurse as deeply as desired.

Related issues #179, #605, docker-library/mysql#192, docker-library/mysql#193

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request Request for image modification or feature
Projects
None yet
Development

No branches or pull requests

3 participants