devcontainers / devcontainers/spec

Optional features (feature groups).

Open
#502 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
5.7k
Forks
496
PR merge metrics
No merged PRs in 30d

Description

# [Proposal] Optional features (feature groups)

One of the shortcomings I've encountered is allowing for slight differences in ci workflows vs local workflows. I was thinking of adding an additional property to the `devcontainer-feature.json` spec that would allow for
*grouping* features between the two environments. Namely, allow for a subset of features to be used in ci workflows via cli flags.

## Proposal

Extend the [devcontainer-feature.json spec](https://containers.dev/implementors/features/#devcontainer-feature-json-properties) with the following property:

| Property | Type | Description |
|----------|------|-------------|
| `group` | string | **Optional** Metadata used for excluding this feature. |

## Example

Consider a devcontainer used for maintaining a gitops related repo. Locally one requires secret management and some manual handling tools, but in CI these tools are not required. A user would mark the features not needed for CI via a group named `local`. Ref:

#### devcontainer.json
```[json]
{
...
"features": {
"ghcr.io/devcontainers/features/aws-cli:1": {"group": "local"},
"ghcr.io/devcontainers/features/docker-outside-of-docker:1": {"group": "local"},
"ghcr.io/devcontainers-contrib/features/sops:1": {"group": "local"},
"ghcr.io/devcontainers/features/node:1": {
"version": "lts"
}
},
...
}
```
When it comes to starting the devcontainer locally, there would be no change to existing behaviour. In CI, one would pass in the flag:

```[bash]
> devcontainer up --exclude-group local
```

This would spin up the devcontainer without the features in the `local` group.

## Plan

I don't mind putting up a couple PRs across the various repo's (cli , ci) to make this a reality, but I'm looking for a green light on the work before I put in the time. Anyhow, I'm open to any feedback, e.g. make the system more extensible with `include` and `exclude` or whatever.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.