Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • gitlab-runner gitlab-runner
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 2,607
    • Issues 2,607
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 107
    • Merge requests 107
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • gitlab-runnergitlab-runner
  • Issues
  • #4125
Closed
Open
Issue created Apr 08, 2019 by Michael Adler@therisen06

Kubernetes executor ignores Docker ENTRYPOINT

Summary

The Gitlab Kubernetes executor overrides the Docker ENTRYPOINT with its own shell snippet. This happens even if the entrypoint directive in .gitlab-ci.yml is used. The behavior differs from the Gitlab Docker executor which does not override the container's entrypoint. That is, given a gitlab-ci.yml file, the outcome of its build job depends on the Gitlab executor being used, whence I consider this a bug. I took a look at the Kubernetes pod specification of the CI build and indeed, the entrypoint is overriden by Gitlab executor. It contains a shell snippet to auto-detect available shells.

This happens both for the build container and the helper container

Steps to reproduce

I have created a minimal project reproducing the bug: It consists of

  • a Dockerfile: Alpine base image + custom entrypoint creating a file in the rootfs
  • a CI job: cat the file generated by the custom entrypoint

It works with Docker executor but fails when run by Kubernetes executor (because the file in rootfs is not generated by the entrypoint).

Actual behavior

The ENTRYPOINT specified in the Dockerfile is ignored.

Expected behavior

The ENTRYPOINT should be executed before Gitlab bootstraps the build environment. If an entrypoint is specified in the Dockerfile, it should be executed by default (opt-out, not opt-in!).

Relevant logs and/or screenshots

Running with gitlab-runner 11.9.0 (692ae235)
  on gitlab-runner-isar-gitlab-runner-59ddc564cf-gb2pr ohg-999t
Using Kubernetes namespace: gitlab
Using Kubernetes executor with image registry.gitlab.com/therisen06/entrypoint-debug:latest ...
Waiting for pod gitlab/runner-ohg-999t-project-11733807-concurrent-0r7mnw to be running, status is Pending
Waiting for pod gitlab/runner-ohg-999t-project-11733807-concurrent-0r7mnw to be running, status is Pending
Waiting for pod gitlab/runner-ohg-999t-project-11733807-concurrent-0r7mnw to be running, status is Pending
Running on runner-ohg-999t-project-11733807-concurrent-0r7mnw via gitlab-runner-isar-gitlab-runner-59ddc564cf-gb2pr...
Initialized empty Git repository in /therisen06/entrypoint-debug/.git/
Fetching changes...
Created fresh repository.
From https://gitlab.com/therisen06/entrypoint-debug
 * [new branch]      master     -> origin/master
Checking out 86d06dfc as master...

Skipping Git submodules setup
$ echo "hello world"
hello world
$ ls -lart /
total 72
drwxr-xr-x   11 root     root          4096 Mar  4 15:43 var
drwxr-xr-x    7 root     root          4096 Mar  4 15:43 usr
drwxrwxrwt    2 root     root          4096 Mar  4 15:43 tmp
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 srv
drwx------    2 root     root          4096 Mar  4 15:43 root
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 opt
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 mnt
drwxr-xr-x    5 root     root          4096 Mar  4 15:43 media
drwxr-xr-x    5 root     root          4096 Mar  4 15:43 lib
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 home
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 sbin
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 bin
-rwxr-xr-x    1 root     root           147 Apr  8 10:22 my-entrypoint.sh
dr-xr-xr-x   13 root     root             0 Apr  8 11:36 sys
drwxr-xr-x    1 root     root          4096 Apr  8 11:36 run
dr-xr-xr-x  173 root     root             0 Apr  8 11:36 proc
drwxr-xr-x    1 root     root          4096 Apr  8 11:36 etc
drwxr-xr-x   12 root     root          2680 Apr  8 11:36 dev
-rwxr-xr-x    1 root     root             0 Apr  8 11:36 .dockerenv
drwxr-xr-x    1 root     root          4096 Apr  8 11:36 ..
drwxr-xr-x    1 root     root          4096 Apr  8 11:36 .
drwxrwxrwx    4 root     root          4096 Apr  8 11:36 therisen06
$ /my-entrypoint.sh ls -lart /
hello from my-entrypoint
Dockerfile
my-entrypoint.sh
$ ls -lart /
total 76
drwxr-xr-x   11 root     root          4096 Mar  4 15:43 var
drwxr-xr-x    7 root     root          4096 Mar  4 15:43 usr
drwxrwxrwt    2 root     root          4096 Mar  4 15:43 tmp
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 srv
drwx------    2 root     root          4096 Mar  4 15:43 root
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 opt
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 mnt
drwxr-xr-x    5 root     root          4096 Mar  4 15:43 media
drwxr-xr-x    5 root     root          4096 Mar  4 15:43 lib
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 home
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 sbin
drwxr-xr-x    2 root     root          4096 Mar  4 15:43 bin
-rwxr-xr-x    1 root     root           147 Apr  8 10:22 my-entrypoint.sh
dr-xr-xr-x   13 root     root             0 Apr  8 11:36 sys
drwxr-xr-x    1 root     root          4096 Apr  8 11:36 run
dr-xr-xr-x  173 root     root             0 Apr  8 11:36 proc
drwxr-xr-x    1 root     root          4096 Apr  8 11:36 etc
drwxr-xr-x   12 root     root          2680 Apr  8 11:36 dev
-rwxr-xr-x    1 root     root             0 Apr  8 11:36 .dockerenv
drwxrwxrwx    4 root     root          4096 Apr  8 11:36 therisen06
-rw-r--r--    1 root     root            46 Apr  8 11:36 debug.log
drwxr-xr-x    1 root     root          4096 Apr  8 11:36 ..
drwxr-xr-x    1 root     root          4096 Apr  8 11:36 .
$ sleep 600

Environment description

Are you using shared Runners on GitLab.com? Or is it a custom installation?

I'm deploying Gitlab runner via helm in a custom Kubernetes cluster

Which executors are used? Please also provide the versions of related tools like docker info if you are using the Docker executor.

Kubernetes executor

Used GitLab Runner version

gitlab-runner 11.9.0 (692ae235)

Edited Dec 10, 2020 by Steve Azzopardi
Assignee
Assign to
Time tracking