## Problem https://gitlab.com/gitlab-org/gitlab/-/merge_requests/245988 adds `Gitlab::Ci::Catalog::Bundle::Reader`, which reads a bundled component (its entry file and the local files it includes, collected by #630810+) from the cell's own object storage given `server_fqdn`, `full_path`, `semver` and `component_name`. Nothing calls it yet. Pipeline creation still resolves every `include: component:` directive against the source project through Gitaly, which is the cost this epic exists to remove. This issue covers connecting the reader to pipeline creation. ## Scope of work - Use the `Gitlab::Ci::Components::InstancePath#fetch_content!` path when the address refers to an official GitLab component. - Resolve the requested reference to a concrete semver against the cell-local tables. See implementation notes. Use one version matcher shared with `InstancePath#fetch_catalog_version`, so both paths always accept the same version formats. - Fall back to the existing source-project path when no bundled row exists. On the default cell this covers non-official components and versions with failed or in-flight backfill. On customer cells the fallback is unreachable for non-bundled components, and the include resolves to an error as it does today. - Memoize the bundled-row lookup and the object download per request, as `InstancePath` does for `project` and `sha` with `SafeRequestStore`, so a component reached twice in one pipeline is fetched once. - Feature-flag the new path for gradual rollout. Default off. - Non-official components, meaning any `verification_level` other than `:gitlab_maintained`, keep using the source-project path regardless of feature-flag state. ## Acceptance criteria - Pipeline creation for an official component with a `catalog_bundled_resource_versions` row uses the bundle when the feature flag is enabled. - Pipeline creation on the default cell for an official component with no bundled row falls back to the source-project path. - Pipeline creation for non-official components uses the source-project path regardless of feature-flag state. - A `~latest` reference and a partial semver reference both resolve on the bundle path. Neither falls through to the source-project path when a bundled row exists. - A pipeline generated via the bundle path is equivalent to one generated via the source-project path for the same version: same job set, same variables, same `include:` resolution outcome. ## Implementation notes **1. Where the bundle path branches off.** It must sit above both guards at the top of `fetch_content!` (`lib/gitlab/ci/components/instance_path.rb:28`): ```ruby def fetch_content!(current_user:) return unless project return unless sha ``` `project` runs `Project.find_by_full_path`, and `sha` runs `find_catalog_version&.sha || sha_by_released_tag || sha_by_ref`. All of those reach the source project and the last can reach Gitaly, so a bundle read placed below the guards has already paid the cost it exists to avoid. Both `full_path` and `component_name` are parsed from the address with no database access, so the lookup is possible above them. **2. Reference resolution is the substance of this issue, not a detail.** `Reader` takes an exact `semver:` string. On the source path, `~latest` and partial references are resolved at `instance_path.rb:195` by `project.catalog_resource.versions.latest(major, minor)`, which needs the source project and is therefore unavailable on a Cell. The bundled equivalent takes no arguments and also excludes prereleases (`app/models/ci/catalog/bundled_resources/version.rb:31`): ```ruby def latest with_semver.without_prerelease.order_by_semantic_version_desc.first end ``` Without a bundled-side resolver that accepts major and minor, every `~latest` and partial-semver reference falls through to the source path. The bundle path would then look like it works while delivering none of the latency improvement on the most common reference form. **3. [#627209](https://gitlab.com/gitlab-org/gitlab/-/issues/627209) gates the latency win, not just Cells.** `sha` and `matched_version` are `strong_memoize_attr`, so branching to the bundle path above the guards keeps `fetch_content!` from triggering them, but `Ci::Components::FetchService` reads both immediately after when it builds its success payload. `sha` only bails early on a nil `project`, so wherever the source project resolves it falls through to `sha_by_ref`, which is `project.commit(reference)` on Gitaly. Skipping that resolution is the whole latency improvement, so the payload has to carry the bundle in place of `project` and `sha`, as #627209 specifies, before this path is worth taking on any cell. ## Authorization The bundle path does not load the source project, so `InstancePath#access_allowed?` cannot run. No permission check is needed on this path: collection (#630810+) only bundles `:gitlab_maintained` components from public projects. The check runs once, at collection, and is not repeated if a source project later changes visibility. The read path cannot enforce this itself. `catalog_bundled_resources` and `catalog_bundled_resource_versions` carry no `verification_level`, so on the bundle path "official" is inferable only from row presence. If bundling is ever widened beyond `:gitlab_maintained`, that change has to solve authorization on the read path. ## Dependencies - Blocked by #627209+, which makes `Reader` return the collected files and has the `FetchService` payload carry the bundle in place of `project` and `sha`. Until then, `File::Component#masked_blob` and `#expand_context_attrs` read both from the payload with `fetch`, so a nil `project` raises in either.