## Executive Summary ### Background & Market Demand Since the launch of GitLab's CI/CD Component Catalog, adoption has been significant across Self manage and GitLab.com. However .com. This success has generated substantial demand from self-managed GitLab customers who want access to the same rich ecosystem of components available on GitLab.com. The growing library of community and GitLab-maintained components represents a valuable resource that self-managed users currently cannot easily leverage. ### Executive Summary Self-managed GitLab customers need seamless access to components from GitLab.com's CI/CD catalog while maintaining synchronization with latest releases. Currently, manual mirroring is complex and time-consuming, creating barriers to adoption and potential inconsistencies across environments. ## Problem Organizations using self-managed GitLab instances face significant challenges when trying to leverage the rich ecosystem of CI/CD components available on GitLab.com: * **Manual overhead**: Current mirroring processes require extensive manual intervention * **Dependency complexity**: Components often have nested dependencies that are difficult to track and maintain * **Synchronization gaps**: No automated way to stay current with component updates * **Air-gapped limitations**: Fully isolated environments cannot access external components at all * **Inconsistent experience**: Self-managed users have a fundamentally different (and inferior) experience compared to GitLab.com users ## Acceptance Criteria There should be three scenarios which this epic needs to resolve: 1. Automatically mirroring/cloning/sync component from .com to self-manage instance - Today users can mirror .com components manually, we need to automate this process 2. Expanding on scenario number 1 while taking into consideration dependencies inside a components 3. Supporting air-gapped environment, dedicated that cant mirror component from .com #### Engineering Assessment TBD #### DRIs - **PM**: @dhershkovitch - **EM**: @manuelgrabowski - **UX/PDM**: @sunjungp - **Group(s)**: ~"group::pipeline authoring" - **Engineering Owner**: @cheryl.li #### Initiative Driver - Product or Engineering? - [x] **Product-driven initiatives (P1/P2/P3)** - P2 - These initiatives require a Product Priority label (P1/P2/P3) - They may also receive GTM tier labels (T1/T2/T3) for external communication - [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components - These initiatives require an Engineering Priority label (E1/E2/E3) - They have internal visibility only and are not externally communicated - Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades ### Hygiene Guidelines :bulb: _See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/ ##### :one: Pre-Interlock - Update epic description with all relevant information - Ensure all dependencies are identified - Apply appropriate labels (see below) - Update interlock status as discussions progress (via label) ##### :two: Post-Interlock: once quarter begins - Update health status weekly (via label) - Document any newly identified risks or dependencies - Link to implementation epics/issues as work begins - Flag any scope or timeline changes immediately <!-- Apply appropriate labels: - [x] Section (section::dev, section::ops, section::sec) - [x] Stage (devops::plan, devops::create, devops::verify, etc.) - [x] Group (group::product planning, group::project management, etc.) - [x] Interlock Priority (Product labels = Interlock Priority::P1, Interlock Priority::P2, Interlock Priority::P3, Engineering labels = Interlock Priority::E1, Interlock Priority::E2, Interlock Priority::E3) - [x] Investment theme (Investment theme::Core-Devops, Investment theme::Security-Compliance, Investment theme::AI across SDLC) - [x] Platforms (platform: GitLab.com, platform: dedicated, platform: dedicated for gov, platform: self-managed) - [x] Subscription tier (GitLab Ultimate, GitLab Premium, GitLab Free) - [x] Quarter (FY27 Q1, FY27 Q2, FY27 Q3, FY27 Q4) - [x] Pre-interlock status label (interlock status::New/Proposal in progress, interlock status::cancelled, etc) - [ ] Post-interlock status label (R&D roadmap status::Executing, R&D roadmap status::Completed) - [ ] Post-interlock, once quarter begins update health weekly (health::on track, health::needs attention, health::at risk) *For guidance on labels, see the [labels guide here](https://gitlab.com/groups/gitlab-org/-/wikis/CXO-Operational-Dashboards/R&D-Interlock-Dashboard#labels-guide) -->