Open Source Blogs
Immerse yourself in SAP open source! Discover collaborative projects, insights into the latest technologies, and best practices in open source development.
cancel
Showing results for 
Search instead for 
Did you mean: 
fwilhe
Advisor
Advisor
0 Kudos
350
This post is part of a series where the Garden Linux development team shares insights into the development process. Find more posts here.

When I started contributing to Garden Linux, I was looking for a good development environment for it. The Garden Linux Builder is heavily containerized, so in theory any container runtime is good enough to build Garden Linux. On macOS, both Docker and Podman have desktop apps available that will start a Linux virtual machine in the background and integrate it nicely into the shell on macOS so it mostly does not feel like working with a virtual machine.

This is good for running containers but it caused some issues when I tried to get familiar with how to build Garden Linux for development purposes.

I wanted a Linux system where I had more control over the operating system, so I looked into alternative options.

I had been using a Debian Testing VM on VMWare for a while which worked good, but it tempted me into having a lot of configuration in that VM which was not automated or reprovisionable. I created snapshots of that VM, but I always had doubts if it was safe to revert the VM to a previous snapshot or if I would lose any configuration I forgot about. Also, since Debian Testing is not a stable distribution, the VM might break with each upgrade.

I discovered that lima can help to get a better setup. Lima is a tool that can automate the setup and provisioning of virtual machines and it is open source. I created a lima VM manifest file that will do the required setup to work with Garden Linux and build the project. I have additional personal setup in a shell script that I'll run each time I create a new instance of that vm. My goal is to not have any manual configuration in the VM that's important. I can delete and re-create the development environment any moment. There is no state in the VM that needs to be backed up.

This can be used in combination with the Visual Studio Code SSH Remote plugin which is a really powerful combination. Once you connected the Visual Studio Code window to the virtual machine via SSH, you get a development experience that is almost the same as if you had linux locally installed. Editing works like in a local directory, and the shell integration automatically opens shells in the virtual machine, no need to SSH into the VM in a separate terminal window.


To recap, this setup gives me the following benefits:

  • Open source development environment

  • Automated, reprovisionable environment independent of my host operating system

  • No worries about backing up any data or configuration from the VM

  • Great editing comfort in Visual Studio Code, almost as if I was working on Linux natively

    • The Remote SSH plugin does do a great job

    • I can run Garden Linux VMs inside the lima VM (nested virtualization)




If you are interested in trying it out, go checkout the instructions in the VM manifest file.