Distributing features & templates · Issue #7 · devcontainers/spec (original) (raw)
The goal is to distribute definitions to distribute the maintenance load. We currently have 3 buckets:
- The main set of definitions will be maintained by the Codespaces team.
- JavaScript and TypeScript definitions will be maintained by the VS Code team.
- Community maintained definitions will continue to be maintained by the community.
For the community definitions there are various levels of self-service, when useful we can use the JS&TS definitions to help dogfood the approach we decide to take. The approaches I can think of are:
- Community submits PRs (like today). In a separate repository (one for all community definitions).
- Initially the product teams would review the PRs. In the future a team of volunteers from the community might do that (e.g., the DefinitelyTyped project does that).
- Community pushes updates themselves. In a separate repository (one for all community definitions).
- New contributors might first contribute through PRs.
- Community contributors can have their own repository for one or several definitions.
a) We maintain a static registry to collect the definitions at build time, later at runtime.
b) We have dynamic registry, definitions are discovered at runtime. New contributors can register definitions themselves.
A dynamic registry where new contributors can register definitions themselves maximizes self-serviceability, but it also raises security concerns. VS Code extensions are using such a model and it is an open issue to add support for cryptographically signing extensions, so authorship can be verified (microsoft/vscode-vsce#191). There is work being done on this that very much looks like it could be used for other types of artifacts too, but it is too early to tell if we could use it for definitions.
I suggest we take the following steps (progressing from 1. towards 3. above):
- Move community contributions to a separate repository.
- Keep updating them with PRs and grant commit rights to long-time contributors.
- Long-time contributors may also start reviewing PRs from the larger community.
- Consider splitting up the new repository further to ease maintenance and introduce a static registry.
- Move JS&TS definitions to a new repository for VS Code. Setup security scans for base images (Community definitions currently do not build their own base images.)
- Move remaining definitions to a new repository for Codespaces. Setup security scans for base images.
- Initially we can collect the definitions at build time. We will consider updating them at runtime later.
Open questions:
- Library scripts are reused across definitions and will need to be copied or pulled/pushed.
- How would the community scan their base images if they had any? I think all the security scans are internal infrastructure.
- Policy-wise unclear if Codespaces can move their base images to the GitHub Container Registry and if they would continue to use the same security scans.