3 ms·

Running VSCode remotely introduces many interesting challenges, mostly due to security. (You are letting your users run any arbitrary code on your infrastructur

Running VSCode remotely introduces many interesting challenges, mostly due to security. (You are letting your users run any arbitrary code on your infrastructure.) However, I guess GitLab already has this sorted out, because of their existing IDE, and they are experts in this area. Also the open source versions of VSCode don't have access to the official VSCode marketplace. (Both VSCodium and coder.com Code Server.) But again that is probably fine here.

leodriesch 4y ago
Users can already run code on their infrastructure with CI jobs, so I’d guess they already have that part figured out. The extensions and settings sync are going to be interesting, especially since they were pretty positive about extension support in the post.
jillesvangurp 4y ago
It's all dockerized and security hardened probably. I'm guessing this is not that much of an issue. At least not any more than the likes of AWS, Google cloud, etc. allowing third parties to run whatever on their infrastructure. Not to say that there aren't any challenges but they aren't new challenges. And of course Gitlab has long been running CI infrastructure which would have the exact same issues.
- shp0ngle 4y ago
  Yeah I know, but I have some indirect experience with this (not at gitlab, of course) and it was hard to figure all out. In short, it's hard to tell if you are doing repeated C++ builds or mining cryptocurrency. But yeah it's not that different from CI.
  - emteycz 4y ago
    What does it matter if you pay for it?
sarki_247 4y ago
GitLab team member here! This implementation will be client-side only, with a selection of extensions allowed. Self-hosted instance admins will be able to enable or create an allow-list of extensions on their instance. You can learn more in this epic: https://gitlab.com/groups/gitlab-org/-/epics/7683 https://gitlab.com/groups/gitlab-org/-/epics/7683
- shp0ngle 4y ago
  Ahh. So users cannot open terminal on your servers, or run a test?

leodriesch 4y ago

Users can already run code on their infrastructure with CI jobs, so I’d guess they already have that part figured out. The extensions and settings sync are going to be interesting, especially since they were pretty positive about extension support in the post.

jillesvangurp 4y ago

It's all dockerized and security hardened probably. I'm guessing this is not that much of an issue. At least not any more than the likes of AWS, Google cloud, etc. allowing third parties to run whatever on their infrastructure. Not to say that there aren't any challenges but they aren't new challenges. And of course Gitlab has long been running CI infrastructure which would have the exact same issues.

shp0ngle 4y ago
Yeah I know, but I have some indirect experience with this (not at gitlab, of course) and it was hard to figure all out. In short, it's hard to tell if you are doing repeated C++ builds or mining cryptocurrency. But yeah it's not that different from CI.
- emteycz 4y ago
  What does it matter if you pay for it?

sarki_247 4y ago

GitLab team member here! This implementation will be client-side only, with a selection of extensions allowed. Self-hosted instance admins will be able to enable or create an allow-list of extensions on their instance. You can learn more in this epic: https://gitlab.com/groups/gitlab-org/-/epics/7683 https://gitlab.com/groups/gitlab-org/-/epics/7683

shp0ngle 4y ago
Ahh. So users cannot open terminal on your servers, or run a test?