Custom docker image fails with `illegal option pipefail` in the gitlab script

Hi

I have a custom docker image (simplified):

FROM ubuntu:19.10

# Update anything that might be out of date
RUN apt-get -qq update \
 && apt-get clean

# Compiler agnostic requirements
RUN apt-get install -y --no-install-recommends \
  git \
  python3 \
  python3-pip \
  && apt-get clean

# Update pip to avoid error messages
RUN pip3 install --no-cache-dir --upgrade \
  pip

ENTRYPOINT ["/bin/bash", "-c"]
CMD ["/bin/bash"]

If I use this image on the shared runners it fails with

sh: 3: set: Illegal option -o pipefail

The script is running with /bin/sh, which links to /bin/dash, which doesn’t have the pipefail option.

Strangely enough, if the ENTRYPOINT and CMD lines are removed from the docker file, it then runs successfully. Either by not trying to set pipefail during the gitlab generated script or by using bash.

I can continue working without the entrypoint, but I am curious as to why this is happening.

Thanks in advance
Paul

1 Like

It sounds a bit strange indeed. I can reproduce it within our configuration. /bin/bash is the default shell for gitlab-runners to use. So I should expect it to use bash and not fail on a pipefail command.

But note that it only make sense specifying an ENTRYPOINT if you want to run a specific script. CMD ["/bin/bash"] is already specified in ubuntu:19.04 so you don’t need it. If you specify “ENTRYPOINT”, it basically means that the script you are running is already inside the image and specified in your ENTRYPOINT. See also: https://docs.gitlab.com/runner/executors/docker.html#the-entrypoint. I don’t know exactly how they implemented it, but in any case, it won’t run the script you specified in the .gitlab-ci.yml.

See https://gitlab.com/gitlab-org/gitlab-runner/issues/1170 for a longer discussion.

It seems like you’ve already found the solution? :slight_smile:

Yes. I know the solution, but I am was wondering why this was happening.

The linked issue seems to have been closed prematurely as the issue persists. Not a serious bug, but the workaround is not obvious for someone that encountered the error the first time.