Deploy DevContainer (& GitHub CodeSpace) to improve UX with a browser-based development environment

[ThibFrgsGmz]

F´ Version	latest
Affected Component	DevEnvironment / Training

---

Feature Description

We should add the functionality of browser-based development environments (devcontainer) based on GitHub CodeSpace.

This consists of creating a .devcontainer folder at the root of the project that contains the files needed for CodeSpace.

There is for example devcontainer.json specifying parameters like:

• a Dockerfile
• VSCode extensions
• extensions, etc.

@astroesteban has already done 90% of the work on adding this feature https://github.com/astroesteban/fprime-devcontainer. It might be necessary to take it back and adapt it to better integrate it to the project.

If he has no more time, I can do the first PR on this feature.

Here is another project on which I saw that they were using CodeSpace in a rather elegant way: https://github.com/nanoframework/nf-interpreter for the embedded domain.

Here is an example of a C++ project from Microsoft to try devcontainers: https://github.com/microsoft/vscode-remote-try-cpp

Rationale

I am convinced that the project will benefit greatly from this.

It will gain contributors and popularity.

Indeed, independent developers who develop in their spare time may be reluctant to spend time on installation issues on their personal devices.

As for professional developers, some don't want to use their personal devices to do what they consider work. In this case, they are subject to installation issues because of their company's IT infrastructure (I've seen this recurring problem).

It will make it easier to train professionals internally.

During a team initiation or training session on the framework, each member just needs a GitHub account and a web browser to explore and do the tutorials in real time.

This will improve the knowledge of the framework at the level of surrounding tools (debugging tool, IDE, real-time linter).

With CodeSpace, we would offer a common reference development environment in addition to the framework.
Each person would start from the same base to explore and develop :

• the same IDE (VSCode): some people are lost at this level alone because they don't know which IDE to choose and only know Eclipse for example.
• the same environment: via a reference Dockerfile automating the installation steps (which put most people off)
• a set of VSCode extensions to improve the user experience: debugger, analyzer, formatter, Intellisense, LiveShare (real-time code collaboration tool).

In my opinion, it will be an essential tool in the years to come with the Ready-To-Code or Pre-Silicon Development (with Renode) trends.

And we can be confident that GitHub will make it even better. Back in June, the company announced that Atom would be shutting down and that the development teams would focus on VSCode and CodeSpace.

[astroesteban]

This would be really useful to get new users up and running as quickly as possible.

@ThibFrgsGmz If this feature gets approved you can take what I have and I'd be happy to be a reviewer.

[ThibFrgsGmz]

@astroesteban Ok, I'm waiting for positive feedback from the maintainers to do the PR.

@LeStarch @thomas-bc Otherwise, I can offer the PR so you can see what the added complexity and maintenance burden is?

[thomas-bc]

I agree that this could be very useful, especially for quick tutorials, interactive demos or even small workshops.
In that case we would want the devcontainer configuration -or at least the Dockerfile- to be "accessible" to other repos (say SystemReference) one way or another, in order to maintain it in a single place. Scrolling through the docs, I feel like it should be doable (especially if F' is a submodule of the repo), but haven't been able to confirm. Do you know what the best practice is for that kind of use case?

A couple notes from looking into CodeSpace, to take into consideration on where we want to go with this:

• There is a time limit on how long CodeSpace can be used for free (generally 2hours/month per user).
• It shouldn't add much (if any) additional maintenance once we have the Dockerfile and devcontainer, since we already maintain a requirements.txt here. That is, if we base the Docker image off of a maintained one like suggested below.

A couple notes for the implementation:

• There's probably value in using one of GitHub's devcontainer base images -- for both maintainability and integration with VSCode and all that. I see they have a couple for C++ projects, which should have CMake and all that kind of stuff already installed. Here's to hoping it also includes Python!

@LeStarch any thoughts?

[ThibFrgsGmz]

For the sharing of the devcontainer coming from a sub-module, I confess that I did not ask myself the question, so I would not know how to answer.

Concerning the limit of use of CodeSpace, indeed it is 2h/month/user which can seem little.

It would be very interesting for workshop presentations: it would allow the audience to handle the framework and follow the demo at the same time as the speaker.

During the previous Flight Software Workshop, I must admit that I was dragging my feet to set up the environment and follow the demos at the same time as the speaker.

Another usefulness of the devcontainer is that it can also be used locally to automate a complete installation (IDE+extension included) as @astroesteban showed in this discussion.

[astroesteban]

Would it be possible to publish an FPrime base image to the Docker Hub registry?
Then the system reference project can have its own DevContainer that just has a FROM fprime:3.1.1 AS base where the fprime:3.1.1 image just has the minimum required packages and tools for building and running FPrime.
Thoughts?

[ThibFrgsGmz]

Yes indeed it would allow to have a more powerful and complete development environment!

In GitHub CodeSpace mode, the devcontainer would point to a default Dockerfile - on ubuntu 20.04 for example.

But for local devcontainers (Digital Twin mode development), the developer could modify the base .devcontainer image to point to a more interesting virtual environment.
As illustrated in nf-interpreter, the developer can modify the devcontainer base image to develop on different targets (AzureRTOS, ChibiOS, ESP32, TI SimpleLink).

In our case, we could imagine reusing the rtems-docker (on SPARC/AARCH64/...) used on cFS, adding an environment for FreeRTOS (which seems to be very much in demand by the community these last years), AzureRTOS, Zephyr...

This would widen the scope of the framework and open the field of possibilities!

This is also in line with #1385.

Note: I just discovered a great repository: https://github.com/dockcross/dockcross that provides cross-compilation toolchains in Docker images.

[thomas-bc]

Note: see @capsulecorplab 's https://github.com/capsulecorplab/fprime-workspace-image

[capsulecorplab]

Just published a pre-release of my environment for building with fprime v3.4.0. Feel free to try it out https://github.com/capsulecorplab/fprime-workspace-image/releases/tag/v3.4.0-rc1.0.0

[LeStarch]

I think this is captured by the above fprime workspace....so I am closing for now.