Draft: Add documentation for GitLab Functions (concrete) execution
What does this MR do?
Adds public documentation for GitLab Functions (concrete) script execution: the benefits over the traditional shell path (including the Kubernetes signal/background-process defects that are structurally absent under concrete), per-executor support and version requirements, how to enable it at runner or job level, and helper image selection.
Key user-facing subtleties documented:
- On the docker executor the concrete helper-image flavor is auto-selected when
FF_CONCRETEis on, but an explicithelper_image/helper_image_flavoroverride bypasses that — users must pick aconcrete-<arch>-<version>tag themselves. - On the kubernetes executor the concrete flavor is never auto-selected;
helper_imagemust be set explicitly. - GitLab Runner 19.3+ recommended (else-branch fix, #39610 (closed)).
Also links the FF_CONCRETE row in the feature-flags table to the new page.
Why?
The migration epic (&21165 (closed)) is moving to customer-facing rollout; users on GitLab.com should be able to trial concrete on a single project and feed back divergences before their fleet is migrated. There was no public documentation for any of this.
Relates to step-runner#405 (docs follow-ups for executor enablement).