What I learned building code that builds (Visual Studio) Code

An automated assembly line for Visual Studio Code on ARM

You can find the code discussed here on Github, and the releases here. If you find this work at all useful, please consider starring the repository. It gives me the warm and fuzzies, but it also lets me (not to mention Microsoft) know that there are users on these platforms.

I’ve lamented recently about the difficulty in keeping my ARM builds of VS Code up-to-date with the master repository.

I want those on Chromebooks and low-end ARM SBC’s like the Raspberry Pi to have a level of access to this tool that is on a par with the experience on other platforms. This hasn’t been the case to date.

The biggest reason for this is that there’s been a lot of manual intervention required in getting the different versions to build, then getting them to a hosting provider in the correct format, with correctly configured APT and YUM repositories, ready for distribution.

It hasn’t helped that I’ve needed to use my own scripts on a non-public build system to achieve this, as it means that others are unable to contribute to this work.

Today I want to share what I’ve been working on. It is my hope that this allows others to participate in getting more platforms supported, and will provide a delivery mechanism for users on ARM devices that parallels the official Insiders channel of nightly Microsoft builds.

So, on to what this new approach is, and how it works.

Everything now lives on Github

This is the most significant change to the delivery of these builds, and something I’ve wanted to do since I started working on this.

Not only is Github the world’s largest and most significant hub for open-source projects, but their stated commitment to education makes it a great fit for a project attempting to bring new tools into the education space in which ARM devices are so popular.

I’ll discuss below how the build system works now, and what the roadblocks have been to using Github previously.

First up, the build system.

The builds are now handled by Travis CI

The previous build system was running scripts on Debian with a melting pot of dependencies configured solely for the purpose of targeting armhf, with some (fairly messy) bash incantations to glue it together.

I’ve discussed this previously, but Travis CI currently has a frozen white-list (for good reasons) which prevented me from just adding the additional APT sources I needed to satisfy the ARM versions of the VS Code dependencies.

I had considered using a different continuous integration system, but Travis is well supported and they generously provide free build agents for open-source software. In any case, going elsewhere would mean re-writing the build scripts from the ground up, which makes adapting changes more difficult later.

More importantly, if fixes and enhancements are to be sent back upstream to Microsoft, it’s critical that these builds run on the same services and infrastructure that the core team is using.

Thankfully, Travis allows an option for the use of sudo and docker to put together a container, which is what I’m now using to form a Ubuntu-based cross-compilation tool-chain at build time.

This tool-chain uses a 16.04 (Xenial Xerus) base image with the required dependencies layered on top for both armhf and arm64. I intend to expand this into a project-agnostic general-use container for CI systems for easily targeting foreign architectures, but I’ll do a seperate write-up for that when it’s ready.

The website and scripts are now hosted on Github Pages

It might seem like moving the website to Github Pages is a footnote in the scope of the builds as a whole, but it’s important for two reasons.

The website being on Github alongside the code brings it into the core repository, keeping everything in one place, and allowing for outside contributors to help with the website and documentation in pull requests too. Most importantly, the website holds the helper scripts used to set up the repositories on ARM devices (SBC’s and Chromebooks). This means that the scripts themselves are now also held in git and can be contributed to by third parties.

And last but not least…

Automatic nightly builds

The key to the automatic builds is a cron job on Travis that, when it runs, pulls the latest commits on the upstream repository into the CodeBuilds repository, with a preference for the local changes.

Astute observers will have noted that this theoretically has the potential to create merge conflicts in future. The big change with this update is that I’m no longer hosting a fork of the main repository, instead favouring a fresh clone of the upstream repository on each build, and applying patches and overlays where needed to make the code build for our targets. The hope here is to make our build system more resilient to changes in the upstream repository so as to avoid manual intervention as much as possible.

I anticipate conflicts to be relatively uncommon going forward, and rectifying them will certainly be much less work than preparing and checking each and every build has been up until now.

This is hopefully just the beginning

It’s my hope that the tool-chain and build system I’m working on will be of use to others in trying to bring first-class ARM support into more projects, and I strongly encourage any fellow developers reading this to think about doing just that.

There’s an enthusiastic and growing community of users out there on these devices right now that is crying out for better tools. Many of these users are kids getting their first real introduction to software development and the technology industry, and are really missing this support.

Why not give them ours?