### Description Current setup of Workspaces through the GitLab Agent for Kubernetes has the primary challenges/issues - Customers don't have container expertise. - Customers have container exposure but don't have Kubernetes expertise. - Customers have container and Kubernetes expertise but the Workspaces setup is cumbersome. - No SaaS offering. - A lot of setup is needed to even try out Workspaces for evaluation. ### Customer Impact Here are some customer data points/examples from customer engagements and zendesk tickets: * https://gitlab.com/gitlab-org/gitlab/-/issues/473627#note_2401935937 * https://gitlab.com/gitlab-org/gitlab/-/issues/473627#note_2416731888 * https://gitlab.com/groups/gitlab-org/-/epics/15648#note_2414007197 * https://gitlab.com/groups/gitlab-org/-/epics/7419#note_2422325696 * https://gitlab.com/gitlab-com/request-for-help/-/issues/2522 * https://gitlab.zendesk.com/agent/tickets/585386 * https://gitlab.zendesk.com/agent/tickets/557671 * https://gitlab.zendesk.com/agent/tickets/513954 * https://gitlab.zendesk.com/agent/tickets/586160 * https://gitlab.zendesk.com/agent/tickets/609888 In https://gitlab.com/gitlab-org/gitlab/-/issues/505764+ , `@DylanGriffith` showcased a PoC on running Workspaces through a CI job ([video demo](https://www.youtube.com/watch?v=TVGkBn726Bk)). Through this investigation, 2 architecture design documents were merged - - https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/reverse-grpc-tunnel-workspaces-and-ci/ - https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/deploy-workspaces-with-ci-runner/ The work described by the former architecture design document will be undertaken in https://gitlab.com/groups/gitlab-org/-/epics/16785+ . Whereas, this epic aims to take this work forward the work described in the latter architecture design document. https://gitlab.com/groups/gitlab-org/-/epics/16785+ is a pre-requisite for this work. ### Why CI Runners CI is one of the most used feature of GitLab. It is a mature feature which is available for `Free`, `Premium`, `Ultimate` tier. It is available for `GitLab.com`, `GitLab Self-Managed` and `GitLab Dedicated` offerings. Hosted Runners are available as a SaaS offering on `GitLab.com` and `GitLab Dedicated`. Thus, it covers a wider tier and wider offering than the current setup. The Hosted Runners on GitLab.com and GitLab Dedicated offer different types of machines with varying CPU/RAM configuration ([1](https://docs.gitlab.com/ee/ci/runners/hosted_runners/linux.html#machine-types-available-for-linux---x86-64), [2](https://docs.gitlab.com/ee/administration/dedicated/hosted_runners.html#machine-types-for-linux---x86-64)). It provides a convenient way to select a specific runner from the list of all runners that are available for the project using tags [1](https://docs.gitlab.com/ee/ci/yaml/index.html#tags). CI Runners support the following architectures - `x86`, `AMD64`, `ARM64`, `ARM`, `s390x`, `ppc64le`, `riscv64` and the following operating systems - `Linux`, `FreeBSD`, `Windows`, `Mac`. It can also be installed through the following mediums - `Docker`, `GitLab Helm chart`, `GitLab agent for Kubernetes`, `GitLab Operator`. ([1](https://docs.gitlab.com/runner/install/index.html)). Additionally, the GitLab Runner Infrastructure Toolkit (GRIT) is a library of Terraform modules you can use to create and manage many common runner configurations on public cloud providers ([1](https://docs.gitlab.com/runner/grit/)). CI Runners allow registration at instance, group, project levels. Thus, it allows the highest level of flexibility in terms of setup. CI has billing features integrated. It also has metrics and dashboards available.([1](https://docs.gitlab.com/ee/ci/runners/runner_fleet_dashboard_groups.html),[2](https://docs.gitlab.com/ee/ci/runners/runner_fleet_dashboard.html)) ### Technical Details We introduce the ability to create a Workspace by utilizing CI Runners. This will be behind a feature flag as we test it out and identify the feature gaps with the existing Kubernetes setup. The existing Kubernetes setup will stay as is and until we transition to the this architecture completely(assuming there are no hiccups), there will be two ways to create a workspace - through Kubernetes(existing) and through CI Runners(this epic). What this translates into is - Identify which Runner executor we want to start with. - Convert a devfile into a CI pipeline definition. - Create a new pipeline every time the workspace starts/restarts. Each pipeline will have a workspace agent injected inside it which will allow us to reverse tunnel traffic and access the traffic inside it. Once we we are able to launch a workspaces through CI Runners, we will identify the feature gaps with the existing Kubernetes setup and additional work that will have to be done to make make this available to wider audiences. More details can be found in https://gitlab.com/gitlab-org/gitlab/-/issues/519307#note_2385146707 . ### Success criteria / Expected outcome - When the feature flag is turned on, user can go to any project on GitLab.com and create a workspace from it without any setup(no custom infrastructure, no custom configuration). This will be powered through CI Runners that are available by default for all projects on GitLab.com. - Other teams are also looking at CI Runners to execute arbitrary jobs e.g. Duo Workflow ([1](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/10875),[2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/176742)). With the work described here, it would unlock value for everyone. - e.g. Debugging a CI job using GiLab VS Code fork. - e.g. Duo Workflows would be able to trigger a CI Job which will run Workspaces with Duo Workflow agents. Once Duo Workflow agents are done with their work, they could provide a URL to the workspace to the user to run, test and verify the code changes. ### Note https://gitlab.com/groups/gitlab-org/-/epics/16785+ was earlier part of this epic . However, https://gitlab.com/groups/gitlab-org/-/epics/16785+ has been moved out because that work has value in itself to be pursued separately. Thus all the issues in https://gitlab.com/groups/gitlab-org/-/epics/16786+ were moved to the this epic to remove unnecessary nesting of issues.