Skip to content

Design for multiple editor support

Background

Today developers can create a workspace on GitLab and choose to provision that workspace in their own Kubernetes clusters. The workspace consists of one or more runtimes such as Golang, ruby, python, etc (decided by an image referenced in a Devfile) and the VS Code IDE. We don't give our customers the ability to select other IDEs such as VIM, JupyterLab, Intelij, etc and we also don't give customers the ability to bring their own IDE injectors (the component that copies the IDE to the runtime images). Both internal (GitLab) and external customers have expressed interest in us supporting a multitude of IDEs.

Design

Principles

We want to create a design that is flexible so that customers can not only select from a list of IDEs that we support but also provide their own container image containing their own version of an IDE. We also want to make sure that administrators can configure the IDE settings at a group level, with the lower group level overriding the settings made at an higher group level. IDE settings should also be available at the instance level which is very helpful for gitlab.com as we can then set default injectors that can be used by all groups.

Database Changes

In order to support multiple IDEs, we need a new object to store IDE selection choices for a group. The IDE selection will cascade downwards, with choices at the subgroup level overriding the group level. We will also have instance level configuration stored in the same object indicated by an empty namespace.

erDiagram
    Namespaces ||--o{ Namespaces: Parent
    Namespaces |o--o{ WorkspaceIDEConfiguration: IDEs
    WorkspaceIDEConfiguration ||--o{ Workspaces: WorkspaceIDE
    Namespaces ||--o{ Projects: Projects
    Projects ||--o{ Workspaces: Workspaces
    Namespaces {
        integer id
        string path
        string kind
        string name
    }
    WorkspaceIDEConfiguration {
        integer id "auto generated"
        string name "name of the IDE e.g. vs-code, jetbrains-rubymine, etc."
        string image "container image to be used for injecting the IDE into the workspace"
        string copy_script_path "script to copy all assets into the workspace that are required to start the IDE"
        string start_script_path "script to start the IDE"
        foreign_key namespace_id "foreign key reference" 
        boolean active "can this IDE be used while creating a new workspaces"
    }
    Workspaces {
        integer id
        foreign_key cluster_agent_id
        string desired_state
        integer max_hours_before_termination
        foreign_key workspace_ide_configuration_id
        string workspace_ide_configuration_image
        string workspace_ide_configuration_start_script_path
        string devfile_ref
        foreign_key project_id
    }
    Projects {
        integer id
        string name
        foreign_key namespace_id
    }

GraphQL

A new GraphQL entity will be added to the group query that would include all the IDEs for the group. The query will walk up the group hierarchy, the moment it finds records corresponding to the group/sub-group, it will stop there and construct a map of IDEs available at the group/sub-group level. We could've continued up the hierarchy to keep constructing a map of IDEs, however this would not allow users to deactivate IDEs for certain groups.

The following API will be called when the user is creating a workspace (after the user has selected a project):

query getIDEList($fullPath: ID!) {
  group(fullPath: $fullPath) {
    id
    workspaceIDEs(first: 100) {
        nodes {
            id
            display_name
        }
    }
  }
}

UI Changes

A UI change will need to be made to allow selection of the IDE when the workspace is created. Additionally we will need to show the selected IDE in the workspace list view. TODO: @jmiocene to provide perspective / mocks.

Reconciliation

The EditorComponentInjector (ee/lib/remote_development/workspaces/create/editor_component_injector.rb) can be updated to accept the WorkspaceIDE id as input. The class would query the object to get the image and start script and add that to the editor injector init container.

Documentation Updates

The Workspaces documentation will need to be updated with steps on how to create an injector. The steps would include how to create the image, best practices such as keeping the image lean and how to register the injector in the IDE list at the group/sub-group level

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by Shekhar Patnaik