### Description Users cannot browse, install, use extensions in the VS Code(fork) that is injected into the workspace. This makes the experience sub-par as extensions are the powerhouse in the VS Code ecosystem. The goal of this epic is for users to be able to use the Open VSX marketplace inside their workspaces. ### How will users specify the extensions for their projects We will use the VS Code ecosystem of specifying recommended extensions in the `.vscode/extensions.json` file of the repository. VS Code automatically asks the users on workspace startup if they want to install the recommended extensions ### Will these extensions and settings be synced across workspaces for the given a user No, that is out of scope. ### Does this need a security review No, a similar security review was done for WebIDE. ### How to enable this UPDATE - https://gitlab.com/groups/gitlab-org/-/epics/12443#note_1847797934 Be default, this would be turned off. Reason - Open VSX is third party extensions marketplace and organizations might have legal and security reasons to not use it. Options available - Instance level setting - **Not feasible** since SaaS customers might not be able to turn it off. - Group level setting - Would need more backend and UI work. However, this is the right approach. - Feature flag using a group actor - We can enable this for select customers while we work on the `Group level setting`. The group can be derived from - the `project.root_namespace` attribute of the agent from which the workspace is being created. - the `root_namespace` attribute of the project from which the workspace is being created. - In either case, the value of the root group would be the same because of our current authorization policies which require an intersect/common-ancestor between the two. - Agent configuration - **Not recommended** for the following reasons - This is an editor related configuration which we are adding in the agent configuration. Would not play well when we add support for multiple editors. - The reason we need a toggle somewhere to turn off marketplace is because of security/legal reasons. Having this control at agent level would mean anyone with write access to the repository can bypass this security/legal hurdle. For such stuff, especially legals, the overriding control should be at the higher level e.g. root group or instance. - Devfile - **Not recommended** for the following reasons - Enabling/disabling marketplaces might have legal challenges. It should not be left to individual projects to decide this. - There wouldn't be a single place for the organizations to "disable marketplace" for everyone in their organization. This would be a problem. Option selected- Feature flag using a group actor where the group is the root namespace of the agent project ### Future enhancements Since the configurations for marketplace are set right before workspace startup., we can provide options for users to use their own extensions marketplace(assume they have hosted their [own Open VSX registry](https://github.com/eclipse/openvsx/wiki/Deploying-Open-VSX))