## Summary [`gitlab-org/gitlab!244245`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/244245) adds the Rails-side setting `Settings.artifact_registry['api_url']` (default `http://localhost:8080`) and documents it in `config/gitlab.yml.example`. That default only applies to source installs and the GDK. GitLab.com runs on the GitLab Helm charts, and the `gitlab.yml` used by the pods is rendered by the charts, which do not pass arbitrary `gitlab.yml` keys through. To give GitLab.com a real value we need to (1) teach the chart to render the key and (2) set the value in the `.com` deployment. ## This is the same pattern as the container registry, minus a few layers The container registry `api_url` is wired the same way, and Artifact Registry follows the common core of that pattern. What we drop: - **Omnibus** — AR is GitLab.com-only, so no `gitlab-org/omnibus-gitlab` work. - **The optional bundled-registry branch** — the chart can optionally deploy a self-contained registry (for GDK / chart-based self-managed), which is what pulls in the `registry` subchart and the in-cluster service-name derivation in `gitlab.registry.api.host`. `.com` does not use that branch, and AR has no bundled option at all, so this machinery simply does not exist for AR. - **Every field that is not `api_url`** — registry also renders `enabled`, `host`, `port`, `key`, `issuer`, `notification_secret`, plus TLS and ingress/hostname config, because registry config feeds many consumers (public ingress, TLS checks, token signing, Geo, event notifications). AR feeds exactly one consumer: the Rails `gitlab.yml` `api_url`. What remains is the common core the registry also uses on `.com`: **one value in the `.com` values file, rendered into `gitlab.yml` by a charts template included in the webservice/sidekiq/toolbox configmaps.** For reference, the container registry on `.com` is itself a separately-run service configured this exact way. From `releases/gitlab/values/gprd.yaml.gotmpl` in `k8s-workloads/gitlab-com`: ```yaml global: hosts: registry: name: registry.gitlab.com ``` ## Scope - [ ] **Charts** (`gitlab-org/charts/gitlab`): render `artifact_registry.api_url` into `gitlab.yml` from a Helm value - [ ] **k8s-workloads** (`gitlab-com/gl-infra/k8s-workloads/gitlab-com`): set the value for `gstg`/`gprd` Explicitly **out of scope**: Omnibus (`gitlab-org/omnibus-gitlab`). ## Reference pattern (charts) - `charts/gitlab/templates/_registry.tpl` defines `gitlab.appConfig.registry.configuration`, included into the rendered `gitlab.yml` by: - `charts/gitlab/charts/webservice/templates/configmap.yml` - `charts/gitlab/charts/sidekiq/templates/configmap.yaml` - `charts/gitlab/charts/toolbox/templates/configmap.yaml` ## Proposed implementation **1. Charts MR** (`gitlab-org/charts/gitlab`) - Add a template `gitlab.appConfig.artifactRegistry.configuration` (new `_artifact_registry.tpl`) that renders only when a value is present: ```yaml artifact_registry: api_url: {{ .Values.global.appConfig.artifactRegistry.apiUrl }} ``` - `include` it in the three configmaps above, next to the registry include. - Add `global.appConfig.artifactRegistry.apiUrl` (default unset) to `values.yaml`, and document it under `doc/charts/`. - Add chart template specs mirroring the registry `gitlab_yml` specs. Note on placement: registry uses `global.hosts.registry.name` because it is a public, ingress-fronted host. AR's `api_url` is a server-side internal endpoint Rails calls (no public ingress), so it belongs under `global.appConfig.artifactRegistry.apiUrl` rather than `global.hosts.*`. Final naming is a call for the charts maintainers. **2. k8s-workloads MR** (`gitlab-com/gl-infra/k8s-workloads/gitlab-com`) - Set `global.appConfig.artifactRegistry.apiUrl` in the `gstg` and `gprd` values to the internal cluster address of the AR service (TBD, confirm with the AR/infra DRI). ## Feature flag The calling code is gated behind a **per-organization** feature flag. This is the safety boundary for rollout: - The `api_url` value is **environment-wide**: it is rendered into `gitlab.yml` for every pod in an environment (e.g. all of `gprd`). It is not per-organization. - The flag is per-organization. So once `api_url` is set in an environment, enabling the flag for any organization in that environment is safe. There is no per-organization value wiring to do. - Nothing hits the AR client until the flag is on for an organization, so an unset `api_url` is inert as long as the flag is off. ## Dependencies & ordering 1. [`gitlab-org/gitlab!244245`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/244245) merged (establishes the key). Prerequisite. 2. Charts MR merged **and** rolled into the chart version deployed to `.com` before the k8s-workloads value can reference it. 3. The AR service must be deployed and reachable in `gstg`/`gprd` before pointing the value at it. 4. Per environment: set `api_url` → verify rendered `gitlab.yml` → then enable the per-organization flag for organizations in that environment. ## Risks - The Rails default is `http://localhost:8080`. On environments where the value is unset, the client would target localhost. This is mitigated by the per-organization feature flag: enabling it for an organization in an environment that still has the localhost default would target localhost. Because the value is environment-wide, the guard is simply "do not enable the flag in an environment until `api_url` is set there." - Consider a defensive guard so that "flag on + `api_url` still at the localhost default" fails loudly (raise/log) rather than silently attempting localhost, in case of a misordered rollout. ## Acceptance criteria - [ ] `artifact_registry.api_url` appears in the rendered `gitlab.yml` on `.com` pods with the correct internal AR address. - [ ] A Rails console on `.com` shows `Gitlab.config.artifact_registry.api_url` returning that address (not `localhost:8080`). Related to #605077 and !244245.