devcontainers / devcontainers/spec
Proposal: Improved multi-repo experience
- Dominant language
- No language data
- Stars
- 5.7k
- Forks
- 496
- PR merge metrics
- No merged PRs in 30d
Description
Codespaces has a [customization](https://containers.dev/supporting#codespaces-specific-properties) key `customizations.codespaces.repositories` for specifying the `permissions` the container user should have on a set of one or more repositories. Currently in the Codespaces implementation, the devcontainer maintainer must also manually clone the repos into the workspace separately which adds a maintenance and clarity burden.
There are likely other use cases and implementations that would be able to take advantage of the dev container specifying one or more repositories to be cloned into a workspace. I've opened this issue to prompt a discussion around those use cases and the best method of specifying.
One option that occurs to me is to add a new top level key `repositories` that could (or requires?) including which repository would be the default `workspaceFolder` if not overridden elsewhere. An example might look like this:
```json
"repositories": {
"my_org/repoA": {
"defaultWorkspace": "true"
"permissions": {
"contents": "write",
"pull_requests": "write",
}
},
"my_other_org/repoB": {
"permissions": {
"contents": "write",
"pull_requests": "write",
}
}
}
```
In Codespaces case, this could be used to automatically clone both the repositories to the environment, set the appropriate user permissions for the token, and set the `workspaceFolder` unless overridden elsewhere.
Contributor guide
Assessment
This issue has not been assessed yet.