Ensure that all the output on bootstrap goes to stderr

[stronk7]

That way we can filter out it if needed, for example if we just want to instantiate a php container to run a php script, we don't want all the bootstrap (entrypoint, ini config...) information to pollute the execution. That way, this will work as expected:

$ docker run --rm moodlehq/moodle-php-apache php -r 'echo "Hi!" . PHP_EOL;' 2>/dev/null
Hi!

And, without discarding stderr, we still get all the information (stdout + stderr):

$ docker run --rm moodlehq/moodle-php-apache php -r 'echo "Hi!" . PHP_EOL;'
Running PHP Configuration fetcher
Checking for php configuration in environment
Running entrypoint files from /docker-entrypoint.d/*
Starting docker-php-entrypoint with php -r echo "Hi!" . PHP_EOL;
Hi!

The only alternative to the above that I can imagine is to completely suppress any output (to both stdout and stderr) in out bootstrap.

Note that I've also tried to send the information to Apache error log, but that was futile, because the images have error.log as alias of stderr.

[stronk7]

Note that this PR has been created as draft because, for some reason, the added tests aren't passing @ GHA (they work perfectly here). I've to investigate that, but created the PR already so you can get an idea about the proposal.

As commented above, the only alternative to this proposal is to, completely, remove all that output/echos.

Ciao :-)

[stronk7]

Making the PR ready for review. It took some good time and debugging to me to understand why it was failing, the reason was that I was not mounting the fixtures directory in the 2 new docker run executions. Naab me!

[stronk7]

(once/if this gets merged, I'll backport to all the branches supporting entry-points and php-ini...)

[andrewnicols]

Was going to ask if oyu think it's worth making it echo based on a DEBUG env var?

[stronk7]

Was going to ask if oyu think it's worth making it echo based on a DEBUG env var?

Not really convinced here, mainly because all that information, now being sent to stderr is also available in the container logs (because the images error.log <==> stderr).

So if anybody want to redirect stderr to /dev/null, to avoid it polluting output... that very same stderr still will be available via docker logs.

$ docker run --rm moodlehq/moodle-php-apache:dev sleep 30 2>/dev/null
...
$ docker logs 1757b03a0d81
Running PHP Configuration fetcher
Checking for php configuration in environment
Running entrypoint files from /docker-entrypoint.d/*
Starting docker-php-entrypoint with sleep 30

So, no convinced. Not sure how many people is using the container that way...