Skip to content

Publish reference implementation #9

Closed

Description

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).

/cc joshspicer Chuck Lantz (@Chuxel) Allison Weins (@2percentsilk) Brigit Murtaugh (@bamurtaugh)

Activity

  1. bamurtaugh commented on Feb 11, 2022

    @bamurtaugh
    Member

    Thanks for opening this!

    up could be split into build and run to make building the image available separately.

    I like this as it feels like it allows for easier iteration on the dev container.

  2. jkeech commented on Feb 11, 2022

    @jkeech
    Contributor

    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.

  3. Chuxel commented on Apr 12, 2022

    @Chuxel
    Member

    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.

  4. chrmarti commented on Apr 13, 2022

    @chrmarti
    ContributorAuthor

    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.

  5. Chuxel commented on Apr 13, 2022

    @Chuxel
    Member

    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.

  6. chrmarti commented on Apr 25, 2022

    @chrmarti
    ContributorAuthor

    Adding an exec command for now. I suggest we add more commands once we have some initial feedback on what we currently have.

  7. bamurtaugh commented on May 23, 2022

    @bamurtaugh
    Member

    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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions