## Goal Provide the basic end-to-end workflow where we can create a workspace from a devfile that's stored in a repository. Commercially-reasonable efforts are made to provide limited support for features designated as “Beta,” with the expectation that issues require extra time and assistance from development to troubleshoot. - https://docs.gitlab.com/ee/policy/alpha-beta-support.html#beta ## Availablity - Self-managed customers hosting workspaces on their own clusters - GitLab.com customers hosting workspaces on their own clusters (i.e. running `agentk` on their infrastructure) - Internal GitLab users on GitLab.com for whom we will host a cluster/s - **Public repositories only to begin with** ## Scope At this stage, I expect to be able to: - Configure an agent to support remote development - Create a workspace from a project that contains a valid devfile - See a list of all my active workspaces - Terminate a workspace - Edit files in a workspace using the Web IDE - Interact with the workspace from the Web IDE's terminal panel ## Prerequisites In order to use this feature, I must: - Be on a Premium or Ultimate plan - Have successfully configured the GitLab Agent for Kubernetes on my cloud service ## Known limitations 1. SaaS users will not have a self-service way to enable the feature 1. We have not load-tested the `kas` service on SaaS to see how the endpoints will handle this at scale. 1. The editor is currently being run *inside* the workspace, which means you have to initiate the editing session from the workspace list. If you start making edits in the Web IDE, you will not be able to open a workspace and connect to it without closing the Web IDE first. 1. Workspaces do not have root access to the containers which is a good security feature but limits the kinds of actions that can be performed in them. 1. You won't be able to connect to a workspace via SSH to edit using a local IDE 1. You cannot create workspace for a private repository since we won't be able to clone the project due to lack of personal user credentials 1. Workspaces do not timeout automatically so a long-running job left in a workspace could run up a significant bill on the customer's cloud provider 1. In order to push code changes from a workspace to a private repository, you have to manually add a PAT or SSH key. Every time a new workspace is created, you will have to do this again. 1. Error handling may be incomplete 1. When you create a workspace for a project in a group, [the group has to contain only remote-development-enabled agents](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/blob/main/doc/mapping-projects-to-agents.md?ref_type=heads#interim-solution). 1. At present, the project cloner within the devfile processor in rails simply clones the devfile repository without any error handling/recovery procedures. This should be made more robust to allow a workspace to be spawned in spite of transient errors. See https://gitlab.com/gitlab-org/gitlab/-/issues/408451+