Allow choosing a remote devcontainer for a repository.

[LeoDog896]

Select Topic Area

Product Feedback

Body

I use devcontainers a lot. GitHub Codespaces has allowed me to efficiently work remotely, and I can easily contribute to OSS, work on private projects, and collaborate with my team while on the go.

However, when people don't have a devcontainer in their repository (in most cases, when the repository only requires one already consistent tool, like Deno), these tools aren't supported by default by Codespaces's default devcontainer. This means you're left with three options:

• Encouraging them to add a devcontainer (weird && a bit of a brandish on their repo)
• Clone and run it locally (unfortunately, this is not an option for developers like me).
• Finnicky ignoring of the devcontainer file in order to brush off the solution (suboptimal)

To alleviate this issue, I think you should be able to choose a devcontainer folder from another repository when opening a Codespace. This can make it many times easier to contribute to a repository that uses a novel tool not integrated into the default devcontainer.

[spenserblack]

I've never done this before, but you could also create a template repo for a codespace (e.g. USER/codespace-deno), select "use this template" ➡️ "open in a codespace", and then clone their repo to work on it, right?

[LeoDog896]

Absolutely! That's actually where I got this idea from (I also have a repo in mine called codespace-deno 😅, but unfortunately I can only use this codespace for playgrounds. This is because the PAT that they supply inside codespaces only allows you to work on one project at a time.

[LeoDog896]

I do use an alternative method (that I edited into the suggestion above).

[cwndrws]

Hi 👋 thanks for writing in. I'll pass the feedback along.

I'm not really sure I see the issue with the first option in your list. Devcontainers are supported by more than just codespaces and it's not super uncommon for folks to put editor-specific configuration into a repository. It's definitely up to repo maintainers what configuration to allow in their repositories, but if they have contributors who want to use one of the editors or services that support devcontainers, it seems pragmatic to add configuration for devcontainers to the repository.

To your second point, you could use a codespace with the default devcontainer like a local machine. Custom devcontainers are nice because it makes configuration consistent across multiple instances of the dev environment, but if you can't have a custom devcontainer, you can still customize a codespace using the default devcontainer by installing tools and configuring them manually. This wouldn't be any different from cloning locally except you would be able to access the environment remotely.

[LeoDog896]

Hi! Thanks for responding!

you can still customize a codespace using the default devcontainer by installing tools and configuring them manually.

I think that's what I was mainly looking for - a way to choose your default devcontainer (the tools you generally use) instead of leaving it up to the arbitrary tool choice GitHub provides for the devcontainers.

[cwndrws]

I was referring to the fact that you can manually install whatever tools you'd like into the normal default devcontainer. Obviously, if you delete that codespace and create another you'd have to install the tools you need again, but that's no different from using a local machine.

Another, more hacky alternative that would accomplish what you are looking for would be to have a dotfiles repository that installs tools. You can read the docs about how to setup dotfiles to automatically run a script when creating a codespace here: https://docs.github.com/en/codespaces/customizing-your-codespace/personalizing-github-codespaces-for-your-account#dotfiles.

[LeoDog896]

Dotfiles was what I was looking for - it's a bit hacky but it works! Thanks!