You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to extract a reference implementation for the dev container spec from our existing implementation. The current proposal is to make a CLI available that can take a devcontainer.json and create and configure a dev container from it.
Splitting it into 2 stages at first:
devcontainer up --workspace-folder .
devcontainer run-user-commands --workspace-folder .
up could be split into build and run to make building the image available separately. run-user-commands runs "postCreateCommand" and other user-provided commands.
Products might choose to add to the container's setup between the two commands (e.g., Remote-Containers starts the ssh-agent forwarding among other things).
up could be split into build and run to make building the image available separately.
👍 This would be great to do. This would also allow us to prebuild devcontainer definitions using the CLI to generate a docker image that can be used as the image. For instance, if we transform the codespaces-linux definition to be a base image + a lot of devcontainer "features", then we would need to build the image through the CLI since it's more than just a plain docker build. But we don't want to spin up a container in that case, we just want to have the image built so we can push it to a registry.
As we've been looking at the reference implementation, there's a couple of important gaps here at the moment. Initally I was thinking the up command would bring up the containers and give you a terminal or accept a command to execute. However, at the moment that's not the case.
So to really say we have a reference implementation, I think we'd need:
exec
...which would allow you to execute a command in the terminal that would take into account userEnvProbe, remoteUser, and remoteEnv.
We'd also then need:
stop
... or down which would bring down the containers since the Ids are not fixed. We can open up what is already coming together and just be clear about these gaps while we continue to work on them.
There might be two stories to tell here: One is about the reference implementation that can be used to build products like Codespaces and Remote-Containers and one is about a CLI that can be used in CI.
We could add a run command to run one-off commands (like an interactive shell) in a temporary container.
Yeah we could add run as well, good point. The exec command would be needed for anyone wanting to use the reference implementation for their own tool/service since w/o a fork you'd still need some way to execute a command that factors in the remoteUser, remoteEnv, and userEnvProbe (whether a server spin up or a direct command), but run would be far more convenient for CI, agreed.
Activity
bamurtaugh commentedon Feb 11, 2022
Thanks for opening this!
I like this as it feels like it allows for easier iteration on the dev container.
jkeech commentedon Feb 11, 2022
👍 This would be great to do. This would also allow us to prebuild devcontainer definitions using the CLI to generate a docker image that can be used as the
image. For instance, if we transform thecodespaces-linuxdefinition to be a base image + a lot of devcontainer "features", then we would need to build the image through the CLI since it's more than just a plaindocker build. But we don't want to spin up a container in that case, we just want to have the image built so we can push it to a registry.Chuxel commentedon Apr 12, 2022
As we've been looking at the reference implementation, there's a couple of important gaps here at the moment. Initally I was thinking the
upcommand would bring up the containers and give you a terminal or accept a command to execute. However, at the moment that's not the case.So to really say we have a reference implementation, I think we'd need:
...which would allow you to execute a command in the terminal that would take into account
userEnvProbe,remoteUser, andremoteEnv.We'd also then need:
... or down which would bring down the containers since the Ids are not fixed. We can open up what is already coming together and just be clear about these gaps while we continue to work on them.
chrmarti commentedon Apr 13, 2022
There might be two stories to tell here: One is about the reference implementation that can be used to build products like Codespaces and Remote-Containers and one is about a CLI that can be used in CI.
We could add a
runcommand to run one-off commands (like an interactive shell) in a temporary container.Chuxel commentedon Apr 13, 2022
Yeah we could add
runas well, good point. Theexeccommand would be needed for anyone wanting to use the reference implementation for their own tool/service since w/o a fork you'd still need some way to execute a command that factors in theremoteUser,remoteEnv, anduserEnvProbe(whether a server spin up or a direct command), but run would be far more convenient for CI, agreed.chrmarti commentedon Apr 25, 2022
Adding an
execcommand for now. I suggest we add more commands once we have some initial feedback on what we currently have.bamurtaugh commentedon May 23, 2022
The reference implementation is now available at https://github.com/devcontainers/cli!
Closing this issue as the CLI repo is published, but please let me know if there's more we should discuss here. Thanks!