Changes for content/handbook/engineering/architecture/design-documents/cells/impacted_features/ci-cd-catalog.md: 29 added lines, 8 removed lines.
Original line number
Diff line number
Diff line
@@ -32,7 +32,7 @@ With Cells, organizations and thus groups and projects are isolated. When a proj
- All cells share the same FQDN (`gitlab.com`), so the system cannot distinguish between local and cross-cell components based on the URL alone
- The current component resolution logic (`Ci::Components::InstancePath`) assumes all components are in the same database
**Impact:**Projects cannot use components published in different cells, severely limiting the catalog's utility on GitLab.com.
**Impact:**Cross-org component inclusion will break when the component's organization is migrated to a different cell, or when the organization is set to isolated. There is no scope to fix this.
### 2.2. Challenge 2: Publishing and Listing Components
@@ -94,7 +94,29 @@ This service would:
- Metrics and usage tracking is a big challenge that also needs to be solved by the service
- Many unknowns remain about service architecture and deployment
## 4. Timeline and Scope
## 4. Evaluation
Intra-org CI component inclusion is assumed.
Given the [low usage of public components from private namespaces](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/218441#note_3167650643),
there is no current business case in solving cross-org component inclusion across cells.
Cross-org component inclusion is allowed today but will break when the component's organization is migrated to a different cell,
or when the organization is set to isolated. There is no scope to fix this.
[Bundled components](https://gitlab.com/groups/gitlab-org/-/work_items/21992) may mitigate this breakage for GitLab-official components,
but not for third-party or user-published components.
### 4.1. Pros
- No cross-cell infrastructure required for component resolution.
- Intra-org inclusion works without any changes.
### 4.2. Cons
- Cross-org component inclusion will silently break on cell migration or org isolation.
- No mitigation for user-published cross-org components.
## 5. Timeline and Scope
### Cells 1.0 (FY25-Q4)
@@ -104,7 +126,7 @@ This service would:
**Priority:** Priority 1-2, marked as "needs attention" health status
## 5. Related Work
## 6. Related Work
### AI Catalog (Issue #549767)
@@ -122,14 +144,13 @@ Self-Managed and Dedicated instances will continue to operate as a single cell,
- The cross-cell component usage solution (#456843) likely can enable SM/Dedicated to use GitLab.com components without manual mirroring
- Current workaround requires manual repository mirroring, which is cumbersome
## 6. Open Questions
## 7. Open Questions
1.**Service Ownership:** How will the Pipeline Authoring group handle operational responsibilities for a new service?
2.**Caching Strategy:** What caching mechanisms are needed to avoid performance degradation from cross-cell HTTP requests?
3.**Global Search:** How does this align with the broader strategy for global search in Cells (Issue #465563)?
4.**Explore Pages:** How will other `/explore` pages (projects, groups, etc.) handle cross-cell discovery?
2.**Global Search:** How does this align with the broader strategy for global search in Cells (Issue #465563)?
3.**Explore Pages:** How will other `/explore` pages (projects, groups, etc.) handle cross-cell discovery?
## 7. References
## 8. References
-[Issue #442195: Publishing to and listing components in the GitLab.com CI/CD Catalog](https://gitlab.com/gitlab-org/gitlab/-/work_items/442195)
-[Issue #456843: How to use components from different Cells](https://gitlab.com/gitlab-org/gitlab/-/work_items/456843)
