Add devcontainer for Codespaces

[goosys]

• closes Add quickstart script for Codespaces environment #2798

Regarding #2798, I'd like to propose an alternative approach.

Codespaces now supports using multiple devcontainer configurations, which means we can keep additional settings without causing conflicts. Based on this, I added an initialization script to the devcontainer to help users get started with this repository more easily.

If you select the “For Codespaces” configuration when launching a Codespace and wait for a moment, the environment will come up with both bin/dev and bin/rspec immediately available.

What do you think?

[goosys]

By creating this Prebuild, I can now spin up any branch of this repository in about 1–2 minutes.

Prebuild:

Start Container:

[nickcharlton]

I started digging back into this last week, because I had a bit of time at last.

I'd already played around with Codespaces on a generic Rails app, which is where I found it to be too slow, so I wanted to explore building a custom image. But what worked 9 months ago no longer does, so I ended up opening a support ticket for it on Monday. I've not heard back yet.

But, prebuilds might solve a good chunk of the problem, it's good to hear it's down to 1-2 minutes!

I'll come back to this as soon as I can, but it's going to be a bit slow because it's something that I'm keen to properly understand myself so it can be reused elsewhere.

[pablobm]

I've been playing with devcontainers lately and I'm still very new to them. This review here is more me trying to understand them better and get your opinions.

At another project, I've been trying to get devcontainers set up too (see openstreetmap/openstreetmap-website#6424). I started from the template provided with Rails (bin/rails devcontainer) and iterated from there. The Rails one is based on the image ghcr.io/rails/devcontainer/images/ruby and uses a separate container for Selenium. I also set up Postgres in a separate container.

My intention was to follow The Rails Way as closely as possible. However it's not been smooth sailing and I have had to work around some issues. The setup you offer here appears to just work? Have you experimented with other ways of setting devcontainers in Rails? Do you have any opinions as to how to best do this?

[pablobm]

Is this necessary? I would have thought it happens already with bin/setup.

[goosys]

With bin/setup alone, bin/rspec fails with Database not found: administrate-prototype_test..
However, it felt a bit verbose, so I refined it slightly.

[pablobm]

So I just lost a couple of hours to this line 😅

This writes the .env file, not just within the container but also my real files. Later I was trying to work with Administrate normally (not with this PR) and the change had stayed in the .env file. The envvar DATABASE_URL has precedence over the setting in database.yml, and I didn't realise it was set. I couldn't understand why it was trying to sign into Postgres with the user postgres (as in this envvar) when I was using a different username in database.yml. I ended up having to debug ActiveRecord and finally found it.

So this line has to go.

[goosys]

Sorry for taking your time on this. 🙇
After taking another look, it didn’t seem necessary after all, so I removed it.

Previously, if this wasn’t added here, I would sometimes run into an error where the database couldn’t be found when running certain commands (I don’t remember whether it was bundle exec or something under bin/*). Because of that, I’d been adding it out of habit.

It seems that the ENV settings in devcontainer.json are applied globally, and after testing again, everything appears to work fine without it.

[goosys]

@pablobm
We could certainly create a devContainer tuned specifically for Rails development, but this setup is intended purely to make it possible to spin up Codespaces quickly and reliably at any time.

In my mind, this is primarily for reviewers: it enables a workflow where they can launch a per-PR environment directly on GitHub, verify the changes, and approve them without touching their local setup.

For that reason, I’m not planning to build a development-optimized configuration. Instead, the goal is to use a generic image (universal:4) and minimize startup time as much as possible.

What do you think?

[nickcharlton]

I thought I'd just publish what I'd already started working on, even though it's not working: https://github.com/thoughtbot/codespaces-demo/tree/custom-config

This is what I was doing at the start of last year. I came back to it towards the end of last year, where I was just trying to confirm everything I'd already tried was working with the plan of then building out something custom for Rails which is a lot faster and less confusing to get up and running with.

However, this is no longer works (even though nothing is meaningfully different from what did work previously). I opened the support ticket around that, but I haven't heard anything in the last two weeks.

[goosys]

@nickcharlton

It looks like a new version of universal:linux was released toward the end of last year.
https://mcr.microsoft.com/en-us/artifact/mar/devcontainers/universal/tags

Since things tend to break as soon as the version changes, I think it might be safer to pin the image using a specific version tag.

[goosys]

This isn’t required for the installation itself, but when it fails, the cause is often unclear, so I’m outputting version information and similar details to the build logs.

[goosys]

Some older PR branches still use older Ruby versions, so I install several versions to allow switching easily via RVM when needed.

[goosys]

Ruby 4.0 isn’t available in the stable RVM release yet, so I’m installing it from master.
Once it becomes stable, I’ll remove this workaround.

[goosys]

Updated to support Ruby 4.0.

[nickcharlton]

After initially waiting for weeks, and then a lot of back and forth with GitHub Support, I finally got my baseline configuration completed. I'm going to look at making a custom image next, but I thought it'd be good to share my parallel progress as it's going along.