Dev Container Features #61
Comments
Chuxel
added
finalization
|
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. |
@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. |
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 |
|
Hello. 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 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
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. |
# diff --git a/README.md b/README.md # index 1a1cea8..a8c294a 100644 # --- a/README.md # +++ b/README.md # @@ -1,188 +1,3 @@ # -# Dev Container Features: Self Authoring Template # +# h6-devcontainers-features # # -> This repo provides a starting point and example for creating your own custom [dev container Features](https://containers.dev/implementors/features/), hosted for free on GitHub Container Registry. The example in this repository follows the [dev container Feature distribution specification](https://containers.dev/implementors/features-distribution/). # -> # -> To provide feedback to the specification, please leave a comment [on spec issue #70](devcontainers/spec#70). For more broad feedback regarding dev container Features, please see [spec issue #61](devcontainers/spec#61). # - # -## Example Contents # - # -This repository contains a _collection_ of two Features - `hello` and `color`. These Features serve as simple feature implementations. Each sub-section below shows a sample `devcontainer.json` alongside example usage of the Feature. # - # -### `hello` # - # -Running `hello` inside the built container will print the greeting provided to it via its `greeting` option. # - # -```jsonc # -{ # - "image": "mcr.microsoft.com/devcontainers/base:ubuntu", # - "features": { # - "ghcr.io/devcontainers/feature-starter/hello:1": { # - "greeting": "Hello" # - } # - } # -} # -``` # - # -```bash # -$ hello # - # -Hello, user. # -``` # - # -### `color` # - # -Running `color` inside the built container will print your favorite color to standard out. # - # -```jsonc # -{ # - "image": "mcr.microsoft.com/devcontainers/base:ubuntu", # - "features": { # - "ghcr.io/devcontainers/feature-starter/color:1": { # - "favorite": "green" # - } # - } # -} # -``` # - # -```bash # -$ color # - # -my favorite color is green # -``` # - # -## Repo and Feature Structure # - # -Similar to the [`devcontainers/features`](https://github.com/devcontainers/features) repo, this repository has a `src` folder. Each Feature has its own sub-folder, containing at least a `devcontainer-feature.json` and an entrypoint script `install.sh`. # - # -``` # -├── src # -│ ├── hello # -│ │ ├── devcontainer-feature.json # -│ │ └── install.sh # -│ ├── color # -│ │ ├── devcontainer-feature.json # -│ │ └── install.sh # -| ├── ... # -│ │ ├── devcontainer-feature.json # -│ │ └── install.sh # -... # -``` # - # -An [implementing tool](https://containers.dev/supporting#tools) will composite [the documented dev container properties](https://containers.dev/implementors/features/#devcontainer-feature-json-properties) from the feature's `devcontainer-feature.json` file, and execute in the `install.sh` entrypoint script in the container during build time. Implementing tools are also free to process attributes under the `customizations` property as desired. # - # -### Options # - # -All available options for a Feature should be declared in the `devcontainer-feature.json`. The syntax for the `options` property can be found in the [devcontainer Feature json properties reference](https://containers.dev/implementors/features/#devcontainer-feature-json-properties). # - # -For example, the `color` feature provides an enum of three possible options (`red`, `gold`, `green`). If no option is provided in a user's `devcontainer.json`, the value is set to "red". # - # -```jsonc # -{ # - // ... # - "options": { # - "favorite": { # - "type": "string", # - "enum": [ # - "red", # - "gold", # - "green" # - ], # - "default": "red", # - "description": "Choose your favorite color." # - } # - } # -} # -``` # - # -Options are exported as Feature-scoped environment variables. The option name is captialized and sanitized according to [option resolution](https://containers.dev/implementors/features/#option-resolution). # - # -```bash # -#!/bin/bash # - # -echo "Activating feature 'color'" # -echo "The provided favorite color is: ${FAVORITE}" # - # -... # -``` # - # -## Distributing Features # - # -### Versioning # - # -Features are individually versioned by the `version` attribute in a Feature's `devcontainer-feature.json`. Features are versioned according to the semver specification. More details can be found in [the dev container Feature specification](https://containers.dev/implementors/features/#versioning). # - # -### Publishing # - # -> NOTE: The Distribution spec can be [found here](https://containers.dev/implementors/features-distribution/). # -> # -> While any registry [implementing the OCI Distribution spec](https://github.com/opencontainers/distribution-spec) can be used, this template will leverage GHCR (GitHub Container Registry) as the backing registry. # - # -Features are meant to be easily sharable units of dev container configuration and installation code. # - # -This repo contains a **GitHub Action** [workflow](.github/workflows/release.yaml) that will publish each Feature to GHCR. # - # -*Allow GitHub Actions to create and approve pull requests* should be enabled in the repository's `Settings > Actions > General > Workflow permissions` for auto generation of `src/<feature>/README.md` per Feature (which merges any existing `src/<feature>/NOTES.md`). # - # -By default, each Feature will be prefixed with the `<owner/<repo>` namespace. For example, the two Features in this repository can be referenced in a `devcontainer.json` with: # - # -``` # -ghcr.io/devcontainers/feature-starter/color:1 # -ghcr.io/devcontainers/feature-starter/hello:1 # -``` # - # -The provided GitHub Action will also publish a third "metadata" package with just the namespace, eg: `ghcr.io/devcontainers/feature-starter`. This contains information useful for tools aiding in Feature discovery. # - # -'`devcontainers/feature-starter`' is known as the feature collection namespace. # - # -### Marking Feature Public # - # -Note that by default, GHCR packages are marked as `private`. To stay within the free tier, Features need to be marked as `public`. # - # -This can be done by navigating to the Feature's "package settings" page in GHCR, and setting the visibility to 'public`. The URL may look something like: # - # -``` # -https://github.com/users/<owner>/packages/container/<repo>%2F<featureName>/settings # -``` # - # -<img width="669" alt="image" src="https://user-images.githubusercontent.com/23246594/185244705-232cf86a-bd05-43cb-9c25-07b45b3f4b04.png"> # - # -### Adding Features to the Index # - # -If you'd like your Features to appear in our [public index](https://containers.dev/features) so that other community members can find them, you can do the following: # - # -* Go to [github.com/devcontainers/devcontainers.github.io](https://github.com/devcontainers/devcontainers.github.io) # - * This is the GitHub repo backing the [containers.dev](https://containers.dev/) spec site # -* Open a PR to modify the [collection-index.yml](https://github.com/devcontainers/devcontainers.github.io/blob/gh-pages/_data/collection-index.yml) file # - # -This index is from where [supporting tools](https://containers.dev/supporting) like [VS Code Dev Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) and [GitHub Codespaces](https://github.com/features/codespaces) surface Features for their dev container creation UI. # - # -#### Using private Features in Codespaces # - # -For any Features hosted in GHCR that are kept private, the `GITHUB_TOKEN` access token in your environment will need to have `package:read` and `contents:read` for the associated repository. # - # -Many implementing tools use a broadly scoped access token and will work automatically. GitHub Codespaces uses repo-scoped tokens, and therefore you'll need to add the permissions in `devcontainer.json` # - # -An example `devcontainer.json` can be found below. # - # -```jsonc # -{ # - "image": "mcr.microsoft.com/devcontainers/base:ubuntu", # - "features": { # - "ghcr.io/my-org/private-features/hello:1": { # - "greeting": "Hello" # - } # - }, # - "customizations": { # - "codespaces": { # - "repositories": { # - "my-org/private-features": { # - "permissions": { # - "packages": "read", # - "contents": "read" # - } # - } # - } # - } # - } # -} # -``` # +Features for Dev Containers. # Recent History # * 85e84fd (HEAD, origin/main, origin/HEAD, main) Merge pull request #2 from hankei6km:topic/shellcheck # |\ # | * 7850264 chore: Add "shellcheck" to devcontainer # |/ # * b0690ff Merge pull request #1 from hankei6km:topic/setup # |\ # | * 3917ebd chore: Add "codespaces" to "customizations" # | * e14e3e9 chore: Add scope-label workflow # | * 408add7 ci: Add sem-pr-label workflow # | * cd9e002 chore: Add init-labels.sh # | * 90301df chore: Update "features" in devcontainer.json # | * 9417cab style: Formatting "devcontainer.json" with prettier # |/ # * f6d0aaf Initial commit
"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.
The text was updated successfully, but these errors were encountered: