Allow startup args to be specified by envvar as well as CMD

[shabble]

The ability to configure various simple aspects via the -c shared_preload_libraries=foo etc is really helpful, but unfortunately Github Actions doesn't allow configuration of the CMD parameter when using a container as a supporting service for a CI job.

This means that at the moment, I don't think there's any good way to make these sorts of startup config changes that can work within Github Actions without making a (granted, very simple) derivative image. The main reason against just doing that is having to keep up to date with new releases of the base-image.

My current solution is an entrypoint-wrapper that just checks if a specific var exists, and adds that to the invocatino of the postgres docker-entrypoint.sh if so, but I wonder if it might be worth considering for the core postgres image?

#826 makes it look like maybe a hard sell, but this has the advantage(?) of being much more general than specific vars for every different usecase.

The actual wrapper/logic could be something like:

#!/usr/bin/env bash
set -eux
if [[ -v "PG_EXTRA_STARTUP_ARGS" ]]; then
    exec /docker-entrypoint.sh $PG_EXTRA_STARTUP_ARGS "$@"
else
    exec /docker-entrypoint.sh "$@" 
fi

(although really, it would be better integrated into the existing docker-entrypoint, I just didn't want to meddle with it downstream...)

and then invoked by
docker run -e 'PG_EXTRA_STARTUP_ARGS=postgres -c shared_preload_libraries=pg_stat_statements' postgres or similar.

Any thoughts?

[yosifkit]

We've had the same request in the past for the docker image but for GitLab CI (like docker-library/docker#12) and my response is the same for GitHub Actions:

This sounds like a failing of the docker [service] runner in the [GitHub Actions]. The services [and container objects should really just include entrypoint and command support].

I would probably work around it by just using the shell runner since the yaml syntax is limited, but there would be extra concerns like the need to clean up the containers at the end or on error that the docker runner probably just does for you.

- docker-library/docker#12 (comment)

(and they eventually realized that customizing the command of a service was useful: https://docs.gitlab.com/ee/ci/services/#setting-a-command-for-the-service)