Add custom entrypoint for the build container for Kubernetes executor
What does this MR do?
This MR makes possible to define a custom entrypoint inside the Job definition for the build container created by the K8S executor. This was already working for services but not for the build container.
If that raises security concerns, FF_KUBERNETES_HONOR_ENTRYPOINT
can always be used to force the usage of the base image entrypoint.
Kubernetes Command
is always a replacement of the entrypoint.
In order to use a specific entrypoint, this one needs to be the Command
.
Current situation:
Build/helper container:
Custom entrypoint | FF KubernetesHonorEntrypoint | Command | Args |
---|---|---|---|
nil |
|
BashDetectShellScript | Image Command |
entrypoint-override |
|
BashDetectShellScript | Image Command |
nil |
|
Entrypoint (default) | BashDetectShellScript |
entrypoint-override |
|
Entrypoint (default) | BashDetectShellScript |
Service containers:
Custom entrypoint | FF KubernetesHonorEntrypoint | Command | Args |
---|---|---|---|
nil |
|
Entrypoint (default) | Image Command |
entrypoint-override |
|
Custom Entrypoint (entrypoint-override) | Image Command |
nil |
|
Entrypoint (default) | |
entrypoint-override |
|
Entrypoint (default) |
With Changes:
Build/helper container:
Custom entrypoint | FF KubernetesHonorEntrypoint | Command | Args |
---|---|---|---|
nil |
|
BashDetectShellScript | Image Command |
entrypoint-override |
|
Custom Entrypoint (entrypoint-override) | BashDetectShellScript |
nil |
|
Entrypoint (default) | BashDetectShellScript |
entrypoint-override |
|
Entrypoint (default) | BashDetectShellScript |
Service containers:
no changes
About what was already present:
From what I can see, it was already possible to override the Command with the image entrypoint (default or override) but only for the services (len(command) == 0
).
if len(command) == 0 && len(imageDefinition.Entrypoint) > 0 {
command = imageDefinition.Entrypoint
}
buildContainer, err := s.buildContainer(containerBuildOpts{
name: buildContainerName,
image: s.options.Image.Name,
imageDefinition: s.options.Image,
requests: s.configurationOverwrites.buildRequests,
limits: s.configurationOverwrites.buildLimits,
securityContext: s.Config.Kubernetes.GetContainerSecurityContext(
s.Config.Kubernetes.BuildContainerSecurityContext,
s.defaultCapDrop()...,
),
command: s.BuildShell.DockerCommand,
})
It seems obvious that this was blocked for the build and helper container for a reason (surely for all the trouble to attach
to the pod if BashDetectShellScript
isn't used ?) .
Why was this MR needed?
As described in the issue, it is possible to use the entrypoint of the image for the Kubernetes Executor with the FF KubernetesHonorEntrypoint
for the build container but it is not possible to define a custom entrypoint when the flag is disabled.
What's the best way to test this MR?
Executing the integration tests is the best way to test the changes. I'm modifying gitlab-runner/alpine-entrypoint
to have a second entrypoint to test.
If using kind:
docker build . -f tests/dockerfiles/alpine-entrypoint/Dockerfile -t registry.gitlab.com/gitlab-org/gitlab-runner/alpine-entrypoint:latest
kind load docker-image registry.gitlab.com/gitlab-org/gitlab-runner/alpine-entrypoint:latest
What are the relevant issue numbers?
Closes #30713 (closed)