Fix kubernetes executor helper image override log

• Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA. As a benefit of being a GitLab Community Contributor, you receive complimentary access to GitLab Duo.

What does this MR do?

Fixes an incorrect debug log statement in the Kubernetes executor.

When using the Kubernetes executor with a custom helper_image value, said image is used (we know this from the underlying container runtime's logs), but debug logs say it's using the default helper image.

The issue is fixed by logging helper_image instead if its in-config value is != "", which is the same mechanism that the Docker executor has here.

This isn't pretty in any of both cases (Docker and Kubernetes), but in the Kubernetes executor's case, I checked why we can't use the image value used in the actual Pod definition and we can't because said Pod definition is never passed to Prepare(...), which is the method that logs this line. The pod definition dies at setupBuildPod(...), where it is no longer passed down the call stack. So, we either log there (ugly); or we keep logging in Prepare(...) using the value from s.Config.Kubernetes.HelperImage (less ugly, IMO), which is what the Docker executor (and this MR) does.

Why was this MR needed?

To fix the issue? IDK

What's the best way to test this MR?

1. Build this MR.
2. Run it with a Kubernetes executor and a custom helper_image value.
3. Read the gitlab-runner logs.

I have this MR's fork running right now and it works as expected. Here are the logs before and after:

Before:

GitLab Runner

$ k logs gitlab-runner-7cc58d9c7b-brxdl | grep gitlab-runner-helper
{"job":<REDACTED>,"level":"debug","msg":"Using helper image: registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-latest","project":<REDACTED>,"runner":"<REDACTED>","time":"2025-06-17T11:34:01Z"}

CRI-O

$ ssh <REDACTED> journalctl -u crio.service | grep gitlab-runner-helper
Jun 17 11:34:01 <REDACTED> crio[183494]: time="2025-06-17T11:34:01.876220162Z" level=info msg="Checking image status: registry.gitlab.com/<REDACTED>/gitlab-runner-helper:latest" id=c02cb20a-432a-4e92-ac59-a71f97e03f22 name=/runtime.v1.ImageService/ImageStatus

As you can see, CRI-O (underlying container runtime) is using the right image from helper_image, but gitlab-runner logs the default one.

After:

GitLab Runner

$ k logs gitlab-runner-6cdd7dc9fc-9lqrx | grep gitlab-runner-helper
{"job":<REDACTED>,"level":"debug","msg":"Using helper image: registry.gitlab.com/<REDACTED>/gitlab-runner-helper:latest (overridden, default would be registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-latest)","project":<REDACTED>,"runner":"<REDACTED>","time":"2025-06-17T11:52:57Z"}

CRI-O

$ ssh <REDACTED> journalctl -u crio.service | grep gitlab-runner-helper
Jun 17 11:52:57 <REDACTED> crio[183494]: time="2025-06-17T11:52:57.953364923Z" level=info msg="Checking image status: registry.gitlab.com/<REDACTED>/gitlab-runner-helper:latest" id=fb9d628f-d6c8-4cd0-8b31-f4c8afa092c4 name=/runtime.v1.ImageService/ImageStatus

When using this MR's build, gitlab-runner now logs the image we're actually using (as reported by CRI-O).

What are the relevant issue numbers?

None, that I know of.