Workspaces
Status | Authors | Coach | DRIs | Owning Stage | Created |
---|---|---|---|---|---|
ongoing |
vtak
|
grzesiek
|
michelle-chen
adebayo_a
|
devops create | 2022-11-15 |
Introduction
A common obstacle faced by developers when first contributing to a project is the setup of their local development environment. The time-consuming process of managing interrelated dependencies and fixing version compatibility issues can be demotivating, especially for those who only contribute occasionally or switch between multiple projects frequently. In complicated environments, development teams may also impose restrictions, authentication credentials, build procedures, and standards that add to the fragile nature of the development environment.
At the end of the day, developers want to spend less time managing their development environment and more time contributing high-quality code. And at GitLab, our mission is to ensure everyone can contribute. With Workspaces, our goal is to eliminate the responsibility of configuring and maintaining a local development environment.
Objectives
See our Workspaces direction page for more information.
Glossary
- GitLab VS Code fork: An internal fork of the VSCode project.
- Web IDE: An IDE built on top of GitLab VS Code fork by adding GitLab context. This IDE runs purely in the browser.
- GitLab VS Code fork for Workspaces: An IDE built on top of GitLab VS Code fork by applying patches making it suitable to use in Workspaces. This IDE runs a server and an optional client which is used to connect remotely.
- GitLab Workflow extension: An extension which adds GitLab features to VS Code.
- GitLab Agent for Kubernetes(agentk): A component for solving any GitLab<->Kubernetes integration tasks.
- GitLab Agent for Workspaces(agentw): A component for solving any GitLab<->Workspace integration tasks.
- GitLab Agent Server(KAS): A server running alongside GitLab Rails application to feliciate connections between different GitLab Agents(agentk, agentw) and GitLab and vice versa.
Overview
Each workspace is run as a group of user provided containers in a Pod in Kubernetes through an integration with GitLab Agent for Kubernetes(agentk). We inject an IDE(e.g. GitLab VS Code fork for Workspaces) in each Pod. We aim to be IDE agnostic. The workspace can either be accessed through GitLab Workspaces Proxy deployed in the user’s Kubernetes cluster or through the bi-directional gRPC tunnel established by the GitLab Agent for Workspaces(agentw) injected in the workspace.
Architecture
See Architecture for Kubernetes setup for detailed implementation details.
Decisions
- 001: Configuration format to use
- 002: Provision compute and storage for a workspace
- 003: Authorizing user to create and access a workspace
- 004: Authentication of user traffic to access a workspace
- 005: Explicitly define the user/group ID of the containers at runtime
- 006: Automatic termination of a workspace
- 007: Create workspaces from private projects
- 008: Use SSH to access non-HTTP services running in a workspace
- 009: Allow mapping of GitLab Agent for Kubernetes(agentk) to groups
- 010: Extensions marketplace for GitLab VS Code fork for Workspaces
- 011: Integrate GitLab Duo features inside a workspace
- 012: Automatic suspension of a workspace
- 013: Create workspaces from private container images
- 014: Default container image and configuration for Workspaces
- 015: Allow mapping of GitLab Agent for Kubernetes(agentk) to GitLab Cluster
- 016: Allow users to run sudo commands inside a workspace
- 017: Allow users to build and run containers inside a workspace
- 018: Remove GitLab Workspaces Proxy to simplify setup
Helpful Links
- Workspaces direction
- Workspaces | Category Strategy epic
- Workspaces | Market analysis
- Create Remote Development Group YouTube playlist
13540d10
)