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	🔴 (default - disabled)	BashDetectShellScript	Image Command
entrypoint-override	🔴 (default - disabled)	BashDetectShellScript	Image Command
nil	✅ (enabled)	Entrypoint (default)	BashDetectShellScript
entrypoint-override	✅ (enabled)	Entrypoint (default)	BashDetectShellScript

Service containers:

Custom entrypoint	FF KubernetesHonorEntrypoint	Command	Args
nil	🔴 (default - disabled)	Entrypoint (default)	Image Command
entrypoint-override	🔴 (default - disabled)	Custom Entrypoint (entrypoint-override)	Image Command
nil	✅ (enabled)	Entrypoint (default)
entrypoint-override	✅ (enabled)	Entrypoint (default)

With Changes:

Build/helper container:

Custom entrypoint	FF KubernetesHonorEntrypoint	Command	Args
nil	🔴 (default - disabled)	BashDetectShellScript	Image Command
entrypoint-override	🔴 (default - disabled)	Custom Entrypoint (entrypoint-override)	BashDetectShellScript
nil	✅ (enabled)	Entrypoint (default)	BashDetectShellScript
entrypoint-override	✅ (enabled)	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)