Bundle git and CA certificates for concrete runner

What does this MR do?

Adds git and TLS CA certificate bundling to the concrete runner, so that job stages (get_sources, cache, artifacts) can execute entirely within the build container without depending on the predefined helper container or the build image having git pre-installed.

Related issue: #39291 (closed)

Context

With FF_CONCRETE, all job stages run inside the build container via the step-runner. Previously, git operations, cache archiving/extraction, and artifact upload/download ran in the predefined helper container, which shipped with git and CA certificates. The build container (a user-provided image) may not have either.

This MR introduces a concrete helper image flavour that bundles git + glibc and CA certificates. During the existing bootstrap phase (where the step-runner binary is copied into the build container), we now also copy the git installation and certs alongside it.

Approach

New concrete helper image flavour

A new build target produces the concrete flavour of gitlab-runner-helper. This image contains:

• A git installation under /git/
• CA certificates at /ssl-certs.pem

When FF_CONCRETE is enabled and no explicit helper image flavour is set, the Docker executor selects the concrete flavour automatically.

Extended bootstrap

The bootstrap phase already copies the step-runner binary from the helper image into the build container. This MR extends it to also copy:

• The /git/ directory (preserving symlinks and permissions)
• The /ssl-certs.pem file

A generic copyDir helper replaces the single-file copy for the binary, supporting recursive directory copies with symlink preservation.

Bundled git and CA cert discovery

On startup, the step-runner resolves the bundled git path relative to its own binary location (<binary_dir>/git/bin/git). If present, all git operations use this path rather than a system git. Similarly, if <binary_dir>/ssl-certs.pem exists, it is set as SSL_CERT_FILE for runner helper commands.

A HelperEnvs() function wraps environment variable maps to inject PATH (for bundled git) and SSL_CERT_FILE (for CA certs). This is applied to:

• All git invocations in get_sources
• Cache archiver/extractor commands
• Artifact uploader/downloader commands
• Pre/post clone scripts (so they also have access to git and valid certificates)

Removal of install_git workaround

The previous temporary workaround that attempted to install git via the system package manager (apk add git || apt-get install git || ...) has been removed. The bundled git replaces it.

Known limitations

Users who extend the helper image with custom tools: If a user overrides the helper image to add tools (e.g., ssh, rsync) that their pre_get_sources_script or post_get_sources_script depends on, those tools will not be available in the build container. This is a known gap. The plan is to detect this configuration (helper image override combined with pre/post clone scripts), warn affected users with a link to a migration guide, and make the breaking change at a major milestone with advance notice. See the linked issue for the full discussion and alternatives considered.

Flavour override: Users who explicitly set a helper image flavour (e.g., ubuntu) will not get the concrete flavour. Before FF_CONCRETE graduates from feature flag status, we have two paths forward:

1. Add the bundled git and CA certs to all standard flavours (alpine, ubuntu, etc.) so that existing flavour selections continue to work.
2. Deprecate helper image flavour selection entirely and consolidate on the concrete image. If concrete provides everything the runner needs (git, certs, step-runner), the other flavours exist only to support users who extended them with custom tools. This would simplify the image matrix and CI pipeline significantly, but would require the same detect-warn-deprecate cycle with advance notice at a major milestone.

See the linked issue for discussion on which path to take.

How to test

1. Enable FF_CONCRETE on a runner using the Docker executor.
2. Run a job with a minimal build image (e.g., busybox) that does not have git installed.
3. Verify that get_sources succeeds (the bundled git is used).
4. Verify that cache and artifact operations succeed.
5. Verify that pre_get_sources_script and post_get_sources_script can invoke git.
6. Verify that HTTPS clones work (the bundled CA certs are used).

What to watch for

• Jobs that previously relied on tools installed in a custom helper image for pre/post clone scripts will not have access to those tools. This is expected and documented above.
• The RUNNER_IMAGES_VERSION is temporarily set to 0.0.0 for development; this must be updated before merge. (Update: bumped this now)