Dev Container Features
Chuxel opened this issue · comments
"Dev container features" are intended to provide an encapsulated, smooth path for configuring a development container. The name comes from the idea that it is useful to be able to just quickly add one or two more "coding or editing features" to your container without digging out installation instructions or copying scripts around. Features are self-contained, reusable units that contain blocks of code install with different entrypoints for different lifecycle events along with needed dev container configuration metadata. When the feature is referenced in devcontainer.json, the install step execute and the appropriate dev container metadata is merged in with other devcontainer.json contents.
This concept has been discussed in various forms in this spec repository and a preview implementation is available in the dev container CLI. The current spec proposal can be found here for including this as a core part of the dev container specification.
This issue is to track feedback and discussion on current core specification proposal. Issue #7 / PR #40 track the idea of a "collection" that can include features that was broken out to cover distribution.
Note that several other proposals related to the topic have been broken out for consideration once the core has been integrated: #91, #73, #60, #59, #58, #57, #44,#35, #21, #2, and #18.
Is there a better place for me to post some questions and feedback than this issue? I'm really interested in the future of the features enhancement for cutting down the need for customized Dockerfiles for much of my work, but want to ask/provide some feedback in the correct place for this.
Thanks for all of ya'lls hard work on this amazing ecosystem.
Is there a better place for me to post some questions and feedback than this issue? I'm really interested in the future of the features enhancement for cutting down the need for customized Dockerfiles for much of my work, but want to ask/provide some feedback in the correct place for this.
@sheldonhull this issue is a great place! This issue is intended to be the place to leave feedback about Features before it's finalized in the spec. We've talked about setting up some sort of Slack/discord/etc for more informal chat/questions but don't have anything in place yet.
Awesome. So quick one. I've been copying and pasting setup library scripts (library scripts) across multiple repos. I know there could be spec changes possible. Is it stable enough though to leverage remote features now as beta level user? Excited about how this will eliminate a lot of code duplication and setup for devcontainer, but if it's alpha level and subject to many breaking changes out of the box, I might have to wait.
@sheldonhull Yep! Right now, spec conversations here are now more about improvements and addressing gaps that early adopters have been bringing up for consideration rather than how the current implementation works. The images that were generated out of microsoft/vscode-dev-containers have also been refactored and moved to devcontainers/images and use the features out of devcontainers/features as a way for folks contributing to the spec to make sure it's working.
Is it stable enough though to leverage remote features now as beta level user? Excited about how this will eliminate a lot of code duplication and setup for devcontainer, but if it's alpha level and subject to many breaking changes out of the box, I might have to wait.
We don't plan on making any new breaking changes to features, although that is a possibility since it's not finalized yet. Features have been around for a few months now, and we recently finished a large change to switch the publishing mechanism to OCI artifacts which has been working well so far. I think it's fairly safe to adopt now even though it's still in beta form.
As one example, many of the images in devcontainers/images are built using features from devcontainers/features, so features are becoming a core building block in the ecosystem.
Hello.
Perhaps this has been discussed elsewhere, but would it be worth adding a field to devcontainer-feature.json to the system requirements?
For example, I know that many features are currently for Debian and Ubuntu.
But in some cases will only work with certain versions of Ubuntu.
I also believe that some of them only work on certain platforms (CPU architecture).
Hello. I'm not sure if this is the right place to report this, but I hope you see this as feedback from a user who has released quite a few devcontainer features.
I recently released version 0.1.1 of ghcr.io/rocker-org/devcontainer-features/r-apt using GitHub Actions and noticed that the 0.1.0 tag was removed.
Is this a GitHub bug?
(I've done many releases and this is the only time I've seen the tag come off)
This feature has not been a problem because it has not been used by anyone yet, but there may be confusion in the future if such a bug occurs with a popular feature.
Hello. I'm not sure if this is the right place to report this, but I hope you see this as feedback from a user who has released quite a few devcontainer features.
I recently released version 0.1.1 of
ghcr.io/rocker-org/devcontainer-features/r-aptusing GitHub Actions and noticed that the 0.1.0 tag was removed. Is this a GitHub bug? (I've done many releases and this is the only time I've seen the tag come off)This feature has not been a problem because it has not been used by anyone yet, but there may be confusion in the future if such a bug occurs with a popular feature.
The action is located at devcontainers/action, so that's the spot to raise, but /cc @joshspicer @samruddhikhandale , could 0.1.0 be getting treated as 0.1 by mistake?
Looking at the action run which attempted to publish 0.1.0, there was a failure with publishing. Hence, it did not publish any of the required semver tags. A retry should help in this case.
However, the action should have prominently failed and shown ❌ so that it was understood by the user.
ℹ️ the action would never attempt to remove an artifact 😄
Created an issue - devcontainers/action#90
Features are now available broadly and in use so closing this issue out. Feel free to raise additional proposals in this repository.