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 line necessary?

[goosys]

This is necessary.

Because the .ruby-version requirement is very strict, Bundler fails even when the Ruby version in the container image is newer than the version specified in .ruby-version, which prevents bundle install from running.
(Is there a way to control this via a Bundler-related ENV, by any chance?)

Also, the Ruby version in the container image is updated to the latest one over time, so we need to explicitly specify the version here to keep it aligned with .ruby-version.
(At the onCreate stage, the source code isn’t available yet, so we can’t read the version from .ruby-version there.)

[pablobm]

No idea about Bundler envvars 😓 But I don't understand, what does rvm list exactly do here? Perhaps it fails if RUBY_VERSION is not available or something like that?

[goosys]

Ah, sorry 🙇
rvm list was just a command for my own verification, so it’s not needed.

[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?