Currently, the createPodSpec method for preparing jobs sets a default entry point of tail -f /dev/null whenever the entryPoint parameter is not set by the runner. There is actually no such parameter in the definition of the prepare job hook. (createOptions, on the other hand, can be passed through, but is ignored.) So all containers are executed with this default entry point.

But this means in particular containers for services are started with this no-op entry point, rather than their default (usually very sensible) entry point and there is no way to override this from the workflow definition! Therefore it doesn't seem possible to use a postgres service container.

It would seem sensible not to override the entry point of these containers, since (at least in the case of examples like postgres) they have entirely sensible defaults built into the container. (Ideally there would be a proper way to set the entry point for services explicitly in the workflow definition, but that's been an outstanding issue for a long time now.)

This would also bring the behaviour in line with the standard GitHub runner, which uses the default entry point of the container (unless createOptions contains an --entrypoint switch).