Since the first release of envbuilder in sept 2023 we got a bunch of really nice releases notes. 🚀
But none included a mention of some form of devcontainer integration with coder. 💔

Coder's concurrents don't care about re-implementing the whole devcontainer spec.
Instead they just use the devcontainer cli and focus their time on the UX and integration.

The only advantage of envbuilder I see is for running workspaces as pod, that's it.
For workspaces as VM envbuilder currently does not make any sense to me.
The official implem is currently much better because it implements the whole spec.
(prebuilds, secrets, merge configs (features, extensions, etc..), output effective conf, lock file, dotfiles, compose...)

As a user I really like coder's flexibility, but the devcontainer DevX is just bad.
It's makes me reconsider less flexible alternatives like daytona.

I hope coder will focus now on filling the feature parity gap with daytona, gitpod and hopefully codespaces.

In a similar way github do, coder should query the SCMaaS provider to know which branches exists and fetch the current configuration.

In short coderd and the agent must be able to parse a devcontainer config.
Respectively before provisioning time and during runtime.

Before the workspace creation form is submitted coderd must fetch and parse the devcontainer config. (for features like secrets, prebuilds, hardware requirements... )

How

1. Add an SCM provider interface + implement each supported providers ( github, gitlab, bitbucket server...)
2. Add a new field kind in coder_parameter. (when kind is set validate field become useless)
   Each values bind to it's own method in coderd.
   Theses methods will autocomplete / validate the coder_parameter through websockets. (they'll use the scm interface for fetching data)
   Config example :

   data "coder_parameter" "repository_url" {
     name          = "repository_url"
     display_name  = "Repository URL"
     default       = "https://hostname/.../repo.git"
     mutable       = true
     # The server would use this field to know it's the repository url.
     kind             = "git_repository"
     # It could also guess the coder_external_auth with the hostname in the url.
     # Not a great UX though, no drop down list of projects and repositories...
     # Could use three separate fields instead, ex: scm_provider (gitlab, bitbucket...), scm_project and scm_repository
   }
   data "coder_parameter" "target_branch" {
     name          = "target_branch"
     display_name  = "Branch"
     mutable       = true
     kind = "git_branch" # point to some server side code that will query the git provider
   }
   data "coder_parameter" "devcontainer_config" {
     name          = "devcontainer_config"
     display_name  = "Devcontainer configuration"
     default       = ".devcontainer/devcontainer.json" # ignored anyway, file may not exists 
     mutable       = true
     kind = "devcontainer_config" # coderd will complete / validate and fetch/parse the file right away for secrets and other features)
   }
   # we could add other values for validating `hostRequirements`... ram, cpu, storage, GPUs...
   # eg: devcontainer_ram, devcontainer_cpu, devcontainer_storage...

First it will improve the DevX with completion / validation on fields like branch , devcontainer config.
And then enable implementing important features such as devcontainer secrets and prebuilds...

Going further