Feature flag rollout: ci_job_token_gitaly_client_name

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

Roll out the feature flag ci_job_token_gitaly_client_name (type: gitlab_com_derisk, group: group::gitaly, milestone: 19.5, default_enabled: false), introduced in !258795 (merged).

When enabled, GitLab Rails sets the Gitaly gRPC call_metadata['client_name'] to gitlab-ci-job for git-over-HTTP requests authenticated with a CI job token. Today those requests reach Gitaly labelled as gitlab-workhorse, identical to an interactive developer clone, so CI traffic is invisible as a distinct source in Gitaly telemetry. This flag gives CI git calls their own identity in that metadata without changing any git behaviour.

What the flag controls

  • Scope: git-over-HTTP requests authenticated with a CI job token (the runner's checkout and every other git call a job makes with CI_JOB_TOKEN).
  • Effect: the client_name value in Gitaly's gRPC call_metadata changes from gitlab-workhorse to gitlab-ci-job for those requests. It appears as grpc.meta.client_name on Gitaly's access-log lines and as the client_name label of gitaly_service_client_requests_total.
  • No change to the git operations themselves, to access control, or to response payloads. This is a labelling change only.
  • No change to concurrency limiting. Gitaly's limiter is keyed by repository; client_name only reaches it through internal_clients, and only for calls that carry no username. Job-token calls carry the job's user (GL_USERNAME), so they stay on the authenticated per-repository budget before and after the flag.

Prerequisites

  • !258795 (merged) merged 2026-10-15 22:58 UTC (4e76b70d); the flag exists in production from the next deploy.

  • gitlab-com/runbooks!11787 (merged) merged (2026-10-12): adds a CI jobs flow to the Gitaly ingress-flow dashboard and makes its Workhorse box match both names. Without it, CI traffic silently disappears from that diagram when the flag flips.

Rollout plan

  • Enable on staging: /chatops run feature set ci_job_token_gitaly_client_name true --staging
  • Confirm a client_name="gitlab-ci-job" series appears in gitaly_service_client_requests_total on gstg and the gitlab-workhorse series drops by a corresponding amount; confirm the ingress-flow dashboard's Workhorse box still equals its two feeders.
  • Enable on production at 10% of time first (the flag has no actor, so percentage-of-time is the only partial rollout): /chatops run feature set ci_job_token_gitaly_client_name 10 --production, watch for an hour, then true.
  • Confirm the same shift on gprd, with no change in ResourceExhausted rates or latency for PostUploadPackWithSidechannel / InfoRefsUploadPack.
  • Leave enabled; open the flag-removal MR once the series has been stable for two weeks (the gitlab_com_derisk lifespan is 2 months from merge).

What to watch

  • Any dashboard, alert or SLO that filters on client_name="gitlab-workhorse" sees that series drop once CI traffic splits off. Expected, not a regression. Known consumers: dashboards/gitaly/ingress-flow.dashboard.jsonnet (fixed by runbooks!11787) and dashboards/gitaly/traffic-sources.dashboard.jsonnet (text only; its per-client panel groups by client_name and picks the new value up automatically). Nothing in metrics-catalog/ or mimir-rules/ filters on client_name.
  • Gitaly's limiter: nothing should move (see above). If ResourceExhausted for job-token calls changes with the flag, that is a finding, not an expected effect.

Rollback

Disable the flag. The client_name label reverts to gitlab-workhorse immediately for all affected requests; no deploy or data migration required.

Removal criteria

Remove the flag check in Gitlab::Workhorse.attribute_ci_job and the flag definition once:

  • it has been enabled fleet-wide and the gitlab-ci-job series has been stable for two weeks with no unexplained change in Gitaly dashboards or limiter behaviour, and
  • runbooks!11787 is merged.

At that point gitlab-ci-job becomes the permanent, unconditional value.

Related

  • gitaly#7473: log the CI job id on Gitaly access-log lines (job-level attribution; needs a Gitaly change first, then Workhorse forwarding).
Edited by 🤖 GitLab Bot 🤖