Dev-Containers on stuartleeks.com

dotfiles tools wrappers

Sat, 27 Aug 2022 21:45:01 +0100

I’m a self-confessed fan of Visual Studio Code’s dev container experience and have a number of posts about them including a list of some of my favourite things with dev containers. I find it productive to be able to capture the pre-requisites for working with a project programmatically, and share it with others working on the project. However, there’s a feature of dev containers that I use heavily which has the potential to break this model: dotfiles.

VS Code Dev Containers and Continuous Integration

Thu, 08 Jul 2021 20:21:12 +0000

Background

Visual Studio Code has a cool feature called dev containers and I’ve got a number of posts about them (and even included a chapter on them in my book on Windows Subystem for Linux (WSL)).

Dev containers allow you to encapsulate the tools/dependencies that your project needs in a container image meaning you can replace the README steps for tool installation that you’d have to manually work through with a Dockerfile that automates it. This makes it much quicker to onboard someone to your project, ensures consistent tooling across the team, and isolates tools in the container making it easier to work with different versions of tools across different projects.

Forwarding copy to clipboard from dev container to Windows Host

Wed, 17 Feb 2021 19:11:12 +0000

Background

I’ve mentioned VS Code dev containers on this blog before and like using them from WSL.

I’m also a fan of azbrowse for working with Azure resources from the terminal, and lately have found myself running azbrowse from within a dev container for various reasons.

There are several features in azbrowse that copy data to the clipboard, and when run from WSL it detects that and copies to the Windows clipboard, which is convenient. When run from a dev container, the experience isn’t so good (a polite way of saying that it doesn’t work).

Visual Studio Code and Dev containers in the Windows Subsystem for Linux (WSL)

Wed, 01 Apr 2020 19:18:23 +0100

UPDATE (2020-04-08): With the 1.44 release of Visual Studio Code (and the corresponding Remote Containers release), the Insiders release is no longer needed as the . I have updated the post to reflect this (update made in vscode dev container on stable release 😁).

Introduction

In my previous post I gave some thoughts on using Visual Studio Code dev containers. Until very recently your source code needed to be cloned in Windows in order to be able to build and run dev containers with Visual Studio Code. While this has still been a great experience overall, I have hit a few edge cases where being able to have my source code in Linux (under WSL) and then create a dev container from there would have been a big help.

Visual Studio Code and Dev Containers

Tue, 31 Mar 2020 20:45:01 +0100

Visual Studio Code has support for Remote Development which is a really cool feature. You can connect to another machine via SSH and work with code there (the language services etc run remotely which is the really cool part!), connect to the Windows Subsystem for Linux, or run your development environment in containers (aka dev containers). The last of these is the topic for this post.

My team has been using dev containers quite heavily for the last few months and found a lot of benefits with them. They allow you to describe your development environment with a Dockerfile and run your tools, terminal and debugger inside that container whilst keeping the editor UI local. This image from the docs shows this split: