| Jesse Glick It is very undestandable that `withDockerContainer` is expected for tool-only images, and as a matter of fact that is exactly what our organization uses it for. Yet, such tool-only container can very easily have an ` ENTRYPOINT` which needs to completely run before the actual sh steps are executed. In our case, we have a Docker container that we use as a Conan (https://conan.io/) tool. Yet, this container has a entrypoint which runs the usual `docker-entrypoint.sh` that is notably responsible for setting up the different remote repositories and log-in to use them. Yet, we observe spurious failure because of the race condition: sometimes the entrypoint had time to complete before the sh steps are executed, sometimes it did not. The problem is clearly addressed by the Docker guidelines: `ENTRYPOINT` is for the container steps that should not be replaced by the client, and `CMD` is exactly for client override. It does not seem reasonable for Docker to execute commands while racing with `ENTRYPOINT`, and it is becoming such a major problem for us that we will have to walk away from this solution if the situation remains as it currently is. |