Honor entrypoint for build and helper images with exec passthrough
What does this MR do?
Allows GitLab Runner to both honor entry point and also function with exec passthrough (exec "$@"
)
This also works with FF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY: true
Why was this MR needed?
Containers with an entrypoint with exec passthrough were not working.
What's the best way to test this MR?
Try to run a container such as Consul image which has exec passthrough https://github.com/hashicorp/docker-consul/blob/5607edeffa1c759ce996b437374be9e6613bdc15/0.X/docker-entrypoint.sh#L114
What are the relevant issue numbers?
close #28807 (closed)
Merge request reports
Activity
Thank you for your contribution to GitLab. We believe that everyone can contribute and contributions like yours are what make GitLab great!
Some contributions require several iterations of review and we try to mentor contributors during this process. However, we understand that some reviews can be very time consuming. If you would prefer for us to continue the work you've submitted now or at any point in the future please let us know.
If you're okay with being part of our review process (and we hope you are!), there are several initial checks we ask you to make:
- The merge request description clearly explains:
- The problem being solved.
- The best way a reviewer can test your changes (is it possible to provide an example?).
- If the pipeline failed, do you need help identifying what failed?
- Check that Go code follows our Go guidelines.
- Read our contributing to GitLab Runner document.
This message was generated automatically. You're welcome to improve it.
- The merge request description clearly explains:
added Community contribution label
@sheininger this seems to achieve desired behavior. Kubernetes treats Command as entrypoint, so if we pass empty array for command, it will honor the entrypoint if the image has one.
Docker Kubernetes ENTRYPOINT Command CMD Args Edited by bdwyertechmentioned in issue gitlab-org/quality/triage-reports#5446 (closed)
- Resolved by Romuald Atchadé
Hi
@gitlab-com/runner-docs-maintainers
, please review this documentation Merge Request.Edited by Marcel Amirault
added documentation twtriaged labels
added 2 commits
changed milestone to %14.6
added [Deprecated] Category:Runner devopsverify grouprunner typebug labels
assigned to @bdwyertech
added Technical Writing docsfeature labels
added 1st contribution label
added sectionops label
mentioned in merge request cip-project/cip-testing/gitlab-cloud-ci!33 (merged)
mentioned in commit cip-project/cip-testing/gitlab-cloud-ci@8a7bba3a
requested review from @ggeorgiev_gitlab
mentioned in commit cip-project/cip-testing/gitlab-cloud-ci@91b9ac0e
mentioned in commit cip-project/cip-testing/gitlab-cloud-ci@ddabb474
mentioned in commit cip-project/cip-testing/gitlab-cloud-ci@bd62c981
added 16 commits
-
9b1a015d...9df4d5ec - 14 commits from branch
gitlab-org:main
- 358420a8 - Adjust entrypoint logic
- 1a5c1999 - Update docs
-
9b1a015d...9df4d5ec - 14 commits from branch
mentioned in issue #28484
mentioned in issue #4125 (closed)
mentioned in issue #28807 (closed)
- Resolved by Romuald Atchadé
@ggeorgiev_gitlab are you able to take a look at this MR please?
I can see the pipeline is failing, but I'm afraid I haven't enough knowledge of the project to provide any pointers.
Thanks
added 119 commits
-
1a5c1999...3f31e1c0 - 118 commits from branch
gitlab-org:main
- ceb11908 - Adjust entrypoint logic
-
1a5c1999...3f31e1c0 - 118 commits from branch
@ggeorgiev_gitlab Did you ever have a chance to look at this? It appears the pipeline is still failing after rebase.
changed milestone to %14.8
added backend label
mentioned in issue #28914 (closed)
- Resolved by Romuald Atchadé
Hi @ggeorgiev_gitlab , would it be possible to address the merge conflicts so we can move ahead and complete the review from our end? Thank you!
added 142 commits
-
ceb11908...0f1a5518 - 141 commits from branch
gitlab-org:main
- b569c1b6 - Adjust entrypoint logic
-
ceb11908...0f1a5518 - 141 commits from branch
- Resolved by Romuald Atchadé
Perhaps this MR could be used to resolve issue #28914 (closed) as well. The scenario for this is an image that has no
ENTRYPOINT
andFF_USE_LEGACY_KUBERNETES_EXECUTION_STRATEGY=false
andFF_KUBERNETES_HONOR_ENTRYPOINT=true
the runner should treat the image as it would whenFF_KUBERNETES_HONOR_ENTRYPOINT=false
. I was pointed here from this comment: #28914 (comment 855880975). Perhaps I'm mistaken, but I don't believe this particular scenario will be handled by the current changes in the MR. Please correct me if I'm wrong.
mentioned in issue gitlab-org/quality/triage-reports#6849 (closed)
changed milestone to %14.10
@ggeorgiev_gitlab I bumped the milestone on this to 14.10 as it was still open.
mentioned in issue #28761 (closed)
added 60 commits
-
e12778cb...c0c64277 - 58 commits from branch
gitlab-org:main
- b9ffc3e9 - Adjust entrypoint logic
- 59f93d95 - Fix mock for test
-
e12778cb...c0c64277 - 58 commits from branch
mentioned in merge request !3221 (merged)
mentioned in issue gitlab-org/quality/triage-reports#7080 (closed)
mentioned in issue gitlab-org/quality/triage-reports#7180 (closed)
mentioned in issue gitlab-org/quality/triage-reports#7255 (closed)
- Resolved by Romuald Atchadé
mentioned in issue gitlab-org/quality/triage-reports#7462 (closed)
requested review from @ratchade
changed milestone to %15.0
- Resolved by Romuald Atchadé
@ratchade I think that your MR (!3401 (closed)) supersedes this one? Do you think we should focus on !3401 (closed) and close this one? Even if it doesn't make it for %15.0 it's in our immediate plans so we should get it in relatively soon
mentioned in merge request !3401 (closed)
added workflowin dev label
removed workflowin dev label
added 201 commits
-
59f93d95...5323ae8a - 196 commits from branch
gitlab-org:main
- 2c6db30a - Adjust entrypoint logic
- e257e522 - Fix mock for test
- f74db4da - Add dockerfiles for runner helper with entrypoint
- c911df75 - Add ci for runner helper image generation
- 2ae68a8f - Add runner helper with entrypoint integration test
Toggle commit list-
59f93d95...5323ae8a - 196 commits from branch
changed milestone to %15.1
Hey @sperols, Sorry for the late answer
I should be tempted to stay that they should be available (exception for variables as files) as at the container creation, the variables are also set. I can give it a quick check to confirm (or not) if it is actually the case.
- Resolved by Romuald Atchadé
- Resolved by bdwyertech
Looking at this MR it isn't directly obvious from first glance if this MR is ready for a review. We recently introduced a new review workflow that makes it easy to indicate if you (and other people who collaborated here) are waiting on a review, and in effect, mark this MR as ready for another set of eyes to look at.
If you think everything is ready for this next step, please run the command
@gitlab-bot ready
. Until further notice I've set your MR to workflowin dev to make it more clear you (and others) are still working on it.Thank you so much for your hard work so far!
added workflowin dev label
@gitlab-bot ready
added workflowready for review label and removed workflowin dev label
Great work on this @ratchade & @bdwyertech
mentioned in commit 56803900
@bdwyertech, how was your code review experience with this merge request? Please tell us how we can continue to iterate and improve:
- Leave a
or a on this comment to describe your experience. - Create a new comment starting with
@gitlab-bot feedback
below, and leave any additional feedback you have for us in the comment.
Have five minutes? Take our survey to give us even more feedback on how GitLab can improve the contributor experience.
Thanks for your help!
- Leave a
Can someone explain how to get this working on Kubernetes? My main problem is that the official gitlab-runner-helper image has no ENTRYPOINT
$ docker inspect gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v15.1.1 | grep -i entrypoint "Entrypoint": null, "Entrypoint": null,
With a custom helper image this works.
Dockerfile:
FROM gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v15.1.1 ENTRYPOINT ["/usr/bin/dumb-init", "/entrypoint"] CMD ["sh"]
I found this information about it !2058 (comment 388341301)
So how can this be fixed? The docker executor injects the ENTRYPOINT but the Kubernetes executor doesn't
https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/executors/docker/docker.go#L181Almost 2 years later and the standard helper image still does not have this entrypoint. I've tried both the ubuntu and the alpine flavors, I have the ca.crt mounted under /etc/gitlab-runner/certs/ directory, and there is no sign in the helper image log it ran update-ca-certificates. We'd very much prefer not to user our own helper image, as that creates bootstrap issues (e.g. to build the helper image, we need the helper image to already exist).
Can we get a response from gitlab?
added linked-issue label