Skip to content

Add remote development workspace support for Windows/macOS

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Problem to solve

Remote development environments support Linux containers. Windows and macOS are not supported yet.

The CI/CD shared runner fleet on GitLab.com SaaS provides these OS environments for customers.

Workaround: There are several commands and tools that can also be run in Linux workspaces.

Intended users

User experience goal

  1. For bringing the infrastructure, platform engineers need to know how from the UX (linking to docs).
  2. For consuming the workspaces, UX should use labels for the agent for Kubernetes for easier filtering and viewing (linux, windows, macos, etc.)

Proposal

Add support for running

  • Windows containers that are provided with a Kubernetes cluster
  • macOS: TBD (no idea to be honest)

Platform engineers need to bring their infrastructure. Kubernetes running windows containers - prepare for troubleshooting docs, and support questions.

The workspaces-proxy that injects the Web IDE / VS Code editor need to be working with provisioning windows containers (and macOS if that is possible?).

Further details

Workloads that include running the dotnet CLI and do not have Windows OS specific dependencies, can be run in Linux containers, similar to CI/CD. Example in this blog post: https://www.codecentric.de/wissens-hub/blog/dotnet-ci-cd-with-gitlab

Apple M1 Silicon might be possible with specific macOS images that run containers. I found https://computingforgeeks.com/run-macos-in-docker-using-docker-osx/

Permissions and Security

Documentation

  • Infrastructure docs for Kubernetes and Windows/macOS workloads (this seems to be complicated)
  • Frontend to select different OS platforms for workspaces
  • Troubleshooting

Availability & Testing

  • Verify docs how to run different OS containers and integrate them into Workspaces
  • Create specific devfile demo projects targeting Windows/macOS (.net, Powershell, OS specific base commands on the CLI)

Risks:

  • Limit this to "bring your own infrastructure" in the first iteration, reduces scope to supporting and troubleshooting workspace integration.

Available Tier

  • Premium/Silver
  • Ultimate/Gold

Feature Usage Metrics

What does success look like, and how can we measure that?

What is the type of buyer?

For "bring your own platform", everyone should be able to bring windows/macos. Since this might bring technical challenges that can create complexity, and requiring support knowledge, my initial suggestion is to limit this to customers.

  • Premium/Ultimate

Providing workspaces as a service on SaaS will need a separate discussion.

Is this a cross-stage feature?

~"group::ide"

What is the competitive advantage or differentiation for this feature?

Links / references

cc @ericschurter

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 🤖 GitLab Bot 🤖