You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Codespaces has a customization 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:
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.
The text was updated successfully, but these errors were encountered:
As a top-level property we would want to support it in local Dev Containers where the user clones the repository containing the devcontainer.json themselves and only then reopens the local folder in the dev container.
Would the default folder layout in Codespaces be /workspaces/mainRepo, /workspaces/repoA, /workspaces/repoB?
The Dev Containers extension also has the Clone in Volume flow where it clones the repository in a Docker volume, in that case it could probably clone the other repositories automatically, similar to how Codespaces is going to implement this.
I guess instead of adding defaultWorkspace, you could let the user use workspaceFolder when that needs to be different from the main repository's root folder.
This sounds a lot like Git submodules, could these be used to achieve what is being asked for by users? E.g., the main repository could have a .devcontainer folder and include the other repositories in top-level folders.
Codespaces has a customization key
customizations.codespaces.repositories
for specifying thepermissions
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 defaultworkspaceFolder
if not overridden elsewhere. An example might look like this: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.The text was updated successfully, but these errors were encountered: