-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Recurse subdirectories for docker-entrypoint-initdb.d functionality #179
Comments
I agree about the main drawback; I'd rather not publish a breaking change. The sorting of a Maybe we just recommend users mount a script and have it run other scripts in their folders. |
@yosifkit I think your second suggestion sounds better than adding another environment variable |
Also, I thought |
My solution is mounting for f in /initdb.d/*.sql; do
echo "$0: running $f"
"${psql[@]}" -f "$f"
done |
A simple solution is to create a file ( #!/usr/bin/env bash
find /docker-entrypoint-initdb.d -mindepth 2 -type f -print0 | while read -d $'\0' f; do
case "$f" in
*.sh)
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 This will recurse all sub-directories inside |
Closing since this is not something we want to add. Since initdb scripts can be sourced (#452) and everything in the script is functionalized (#496), a custom script in initdb can easily use the Related issues #179, #605, docker-library/mysql#192, docker-library/mysql#193 |
Over in postgis/docker-postgis#35, I had a user ask about adding their own script to
/docker-entrypoint-initdb.d
viadocker-compose
without overwriting the script I use for initializing PostGIS. My suggestion was to bind-mount individual scripts, but it dawned on me that it might be nice to be able to add scripts to subdirectories of/docker-entrypoint-initdb.d
and have them sourced or executed according to the existing logic.The main drawback I see of making this change is that it's possible that existing users of the
postgres
image may already have files in subdirectories of/docker-entrypoint-initdb.d
that they don't want to have executed directly by thepostgres
entrypoint. Another minor but solvable issue is maintaining the execution order of the scripts, which I believe I documented when this functionality was originally added:The text was updated successfully, but these errors were encountered: