Between Google I/O and Microsoft Build it was a busy week, and then there were other interesting releases as well. Too much to choose from so today I’ll focus on some dev tools. Which in this case means GitHub’s new Package Registry, Microsoft’s WSL 2 and new terminal, and sharing encrypted AMIs across accounts in AWS.

GitHub Package Registry

GitHub released a package registry. In case it’s not entirely clear what that is, it’s basically a place to store your compiled and/or packaged code ready for distribution. Two of the best-known package registries out there are npm, for JavaScript libraries, and Docker Hub, for Docker containers. GitHub offers alternatives for both of these¹, as well as supporting the default packages for Java, .NET, and Ruby.

I like to think that this is a good move on GitHub’s part. Obviously it ties in with GitHub Actions in a strategy to provide a complete solution for the development pipeline. And I can’t really find a fault with that. All of this ties together well, and having a single place to store these artefacts makes things easier. It’s certainly easier for a small team² to use this than having to manage your own artefact repository.

Now, is it perfect? I haven’t had a chance to play with it, but I suspect not as it’s still in a public beta³. For one, there are definitely more types of package that would be good to see there. However, I believe that once this and GitHub Actions are available to everyone it will make certainly solve some pain points.

WSL 2 and a Terminal

One downside that Windows has had in the past⁴ is that it didn’t have a proper command line you can use for commands. I’m sure plenty of people will disagree and point out how awesome PowerShell is, but that just never worked for me. I like to be able to drop down to a command line that has all the Unix-y tools that I’m familiar with and be able to customise completely.

This need was first addressed by the release of WSL⁵ which allowed you to run various distributions of Linux inside your Windows. That was pretty good, and it’s great to see that they now announced a new and improved version. Where WSL 1 had a translation layer that still used the Windows kernel under the hood, WSL 2 is a lightweight VM that runs a proper Linux kernel. Because of this it can support commands that didn’t natively work before. There is still integration with the rest of Windows as well.

Together with this, there is also the new terminal client they released at the same time. While not very exciting in itself⁶, I really am quite happy to see a good default terminal client in Windows. Based on the blogpost it, you can use the same client to access the old-school Windows cmd, Powershell, or any WSL distributions you’ve got running. That is really nice and shows that there really is a good integration with WSL. Also, I can’t stop myself from sharing this introduction video that looks more like the promo for a high-end phone.

Cross-Account Encrypted AMIs

Stop me if you’ve been in this situation before. You use AWS and have separate accounts for production and non-prod, as well as yet another one for your CI/CD tooling. You bake your AMIs for deployments in your CI/CD account and as you’re security conscious that means you wish to deploy the same encrypted AMI to both your non-prod and production accounts. And then you realise that you can’t share encrypted AMIs and have to build in workarounds that involve encrypting the AMI in the target account.

Personally I’ve had this situation crop up regularly⁷ so I’m really happy that this is no longer an issue and you can share encrypted AMIs across accounts. This will make it a lot easier to ensure that all the different accounts run the exact same image⁸, deploy faster, and I also don’t have to deal with cleaning up copies in every single account anymore.