Contributor how-to: Remote Development workspaces and GitLab Developer Kit

Open source is fundamental to GitLab. We believe that everyone can contribute.
Typically, we recommend that anyone contributing anything more than basic changes to GitLab run the GitLab Development Kit (GDK). Because contributors can't always meet the GDK's resource demands, we're working to enable GDK inside the cloud-based GitLab Remote Development workspaces.

In this article, I'll explain how I used a Remote Development workspace running in my Kubernetes cluster to make working with the GDK faster and easier.

A preliminary note

First, keep in mind that as of this writing the Remote Development workspaces feature is still in Beta. My example here is therefore very much a proof of concept — and as such, it has some rough edges.

Before getting started, I followed the "Set up a workspace" prerequisites guide in the GitLab docs. For a more detailed set of instructions, see Senior Developer Evangelist Michael Friedrich's tutorial on how to set up infrastructure for cloud development environments.

Getting started with workspaces

To start using workspaces, you will need a project configured with a .devfile.yaml. GitLab team members have curated a number of example projects you can review.

Initially, I tried to do this with a fork of the GitLab project itself, but I ran into some issues when the workspace begins cloning the repository.

To figure out what was causing my problems, I looked more closely at what happens behind the scenes when a workspace is created.

Behind the scenes with Remote Development workspaces

When you create a new workspace, the following happens:

1. The GitLab agent for Kubernetes creates a new namespace in your cluster. The agent dynamically generates a name for and assumes management of the namespace.
2. Inside the namespace, a new deployment is created, specifying the container you chose in your .devfile.yaml as the image to use.
3. This deployment is configured with some init containers that perform some actions:
   1. Cloning the repository into /project/${project_path}.
   2. Injecting the VS Code server binary into your container.
4. Once those init containers are complete, your container starts and the workspace becomes available.

The clone problem

When cloning a repository, git tends to do much of the work in memory. This can be a challenge on larger projects/repositories, as it can require significant amounts of RAM. When cloning the GitLab project, for instance, git consumes approximately 1.6GB of RAM. This number is only going to increase with time. Sure, strategies like [shallow clones](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt