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 Topics Snippets
  • Register
  • Sign in
  • gitlab-runner gitlab-runner
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 3.8k
    • Issues 3.8k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 100
    • Merge requests 100
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
    • Model experiments
  • Monitor
    • Monitor
    • 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
  • #2692
Closed
Open
Issue created Aug 24, 2017 by Blake Hitchcock@rbhitchcock

Extended Docker configuration options for image entrypoint seem to not be working as documented

Summary

While following the documentation here, I was unable to successfully override the entrypoint of the image I was using in my test to /bin/sh.

Steps to reproduce

Snippet of .gitlab-ci.yml

validate_packer_file:
  stage: linting
  except:
    - tags
  image:
    name: hashicorp/packer:light
    entrypoint: ["/bin/sh"]
  script:
    - /bin/packer validate packer_relay.json

This is essentially what the documentation suggests doing if the Docker image specifies an entrypoint.

Actual behavior

When running the test, I get the following output from the Runner:

# snip
Checking out de3081e4 as ami...
Skipping Git submodules setup
/bin/sh: can't open 'sh'
/bin/sh: can't open 'sh'
ERROR: Job failed: exit code 2

After some digging, I determined this to be because the container was still being started with sh as the command, so the container was trying to execute /bin/sh sh which apparently does not work.

Expected behavior

Based on the documentation provided, I would expect my configuration to not cause an error.

Relevant logs and/or screenshots

Running with gitlab-ci-multi-runner 9.5.0 (413da38)
  on aws_docker (c00515ef)
Using Docker executor with image hashicorp/packer:light ...
Using docker image sha256:d6b9eed0071936bb6bdf482ec72618b93a30d1f033b82f0159a9251023dbb127 for predefined container...
Pulling docker image hashicorp/packer:light ...
Using docker image hashicorp/packer:light ID=sha256:36767633ab7b4958d25f19f5e4195bd4bbe57064755166c22983443aefab8c18 for build container...
Running on runner-c00515ef-project-2170336-concurrent-0 via ip-0-0-0-0...
Fetching changes...
HEAD is now at de3081e forget shared runners
Checking out de3081e4 as ami...
Skipping Git submodules setup
/bin/sh: can't open 'sh'
/bin/sh: can't open 'sh'
ERROR: Job failed: exit code 2

Environment description

I'm using Docker version 1.13.0

Used GitLab Runner version

I'm using gitlab.com and a privately hosted runner.

root@ip-0-0-0-0:~# gitlab-ci-multi-runner --version
Version:      9.5.0
Git revision: 413da38
Git branch:   9-5-stable
GO version:   go1.8.3
Built:        Tue, 22 Aug 2017 13:35:13 +0000
OS/Arch:      linux/amd64

Workaround

If I set the entrypoint to an empty string, I am able to get the desired behavior.

validate_packer_file:
  stage: linting
  except:
    - tags
  image:
    name: hashicorp/packer:light
    entrypoint: [""] # force an empty entrypoint
  script:
    - /bin/packer validate packer_relay.json

This may be the intended implementation and there is just a documentation error (or I am misinterpreting the docs).

Thank you for all the hard work! Gitlab CI is a fantastic tool.

Assignee
Assign to
Time tracking