Override entrypoint so we can use images with non-shell entrypoint set (Docker)

Set the Entrypoint to env, this way we end up calling env bash (or whatever the runner has decided the shell is) and then running the build commands inside the shell. This seemed better / safer than explicitly specifying bash or getting it from the .gitlab-ci.yml or something.

I don't want to override entrypoint, because it allows you to prepare container context as it's done here: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/dockerfiles/dind/Dockerfile

The better option is to change shell command to: /usr/bin/env bash.

Do we assume the shell is always bash? I'll try track down where that is defined in the code, if you can give a pointer that'd be helpful though. (This is my first foray into Go, and I've done very little C/C++ type stuff before)

Yes, the generated script is only-bash compatible.

https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/shells/bash.go#L131

Ok, just tried that but the problem is still there. If we can't override entrypoint what else can we do to get around this issue?

gitlab-ci-multi-runner dev (HEAD)
Using Docker executor with image engci-docker.cisco.com:5006/testtng ...
usage: tng [-h] [--version] [-v] <command> ...
tng: error: argument <command>: invalid choice: '/usr/bin/env bash' (choose from 'run', 'archive', 'test', 'unarchive', 'shell')

ERROR: Build failed with: exit code 2

So because the image has ENTRYPOINT tng we are trying to run tng /usr/bin/env bash which is obviously not going to work :S

Maybe we could have some override_entrypoint boolean that could come all the way from the .gitlab-ci.yml along with the image specification?

I'm not happy with that solution. Maybe you can create your own Dockerfile that will override the entrypoint?

Prior art: https://github.com/wercker/support/issues/24 and http://devcenter.wercker.com/docs/containers/entrypoint.html.

Has there been any ideas or movement on this? Creating a custom docker image for building is a valid solution, but the ability to override the entrypoint still seems useful as well. I have a custom image built with the following:

FROM composer/composer
ENTRYPOINT []

Having to create a custom image simply for overriding the entrypoint seems like overkill. composer/composer has an entrypoint of composer and this doesn't work with gitlab-ci.

Is there a reasonable example of the "wrapdocker" entrypoint script that is referenced here: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/dockerfiles/dind/Dockerfile#L18?

Since there is no reasonably safe way to set credentials anywhere in GitLab CI (other than putting them in clear text somewhere--see https://gitlab.com/gitlab-org/gitlab-ce/issues/14178#credentials), I would like to write an entrypoint script that loads some things from a mount before GitLab CI runs; however, when you use an entrypoint, the CMD directives are passed as arguments.

I'm gonna close this. Since learning some more about Docker and getting more use, it is clear that the example I gave in the initial few comments was an incorrect use of the ENTRYPOINT in the Docker image / Dockerfile.

ENTRYPOINT is different to CMD. The latter is a default command which is overridden with arguments after the Docker image name in the docker run ... command, whereas with ENTRYPOINT the arguments get appended to the arguments list specified.

For example if you have the following:

FROM python
ENTRYPOINT ["python"]

Then ran a docker build followed by docker run my_python_image foo.py then inside the container we'd get python foo.py executed. If we had used CMD in the Dockerfile then it would have gotten overridden by our Docker run command and we'd end up just running foo.py inside the container.

Status changed to closed

So, since this is closed, the only option for using third-party images that define ENTRYPOINT is to publish our own set of images that mirror them, but overriding ENTRYPOINT? That seems like a pretty poor solution.

This works, but it's going to result in a lot of custom Docker images being published; for example, there is a Node.js package I'm trying to set up with automated builds through GitLab CI. Since we want builds for each major Node.JS version since 0.10, that means I'll need to create and publish 5 separate Docker images based directly on the ones at https://hub.docker.com/_/node/, and then try and keep up with new versions being published there so we can stay up to date... If we could override ENTRYPOINT from .gitlab-ci.yml, no new images would need to be created, published, or maintained -- I could use the official images directly.

@ian.c.ward: There is a page for setting "Secret Variables" in the project settings; those variables will then be set in the environment of any CI jobs. From what I understand, those are supposed to be relatively secure, and usable for credentials.

I didn't actually realize this was an MR instead of an issue; I'll open an issue for this.

mentioned in issue #1421 (closed)

@whitelynx

Maybe we could use a special purpose variable to overwrite a ENTRYPOINT?

What do you think @tmaczukin?

@ayufan Like with GIT_DEPTH and GIT_STRATEGY? We can try and see how this will behave.

Yes

Hello guys, this is something done or not ?

From https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/executors/docker.md#the-entrypoint looks like not :/

(this is quite a good thing, because many official Docker images has specific entry-point).

Thanks you,

Without this, you just prevent more than half official Docker images to be used here :/

Is there any update on this and if it's even possible without a fair amount of work?

@jamesgoodhouse To not repeat myself: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/1421#note_25399885