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
Today, if I go to the dotnet/runtime repository to create a Codespace with the default configuration from the Code button (without clicking the chevron):
This will create a codespaces with 2 cores and 4 GB of RAM. Even with a pre-built container, this offers a somewhat rough experience. Between the VS Code and server-side extensions using some resources, running ./dotnet.sh test src/libraries/System.Security.Cryptography/tests will OOM.
While it would be nice if things worked in this configuration for folks that want to use the lowest possible billing rate, the frequent OOMs I encountered while using this configuration make me think we need to set a floor on the Codespaces configuration.
You can do this with the hostRequirements section in .devcontainer/devcontainer.json. I am proposing we add this:
Folks can always change the specs after they create the codespaces, but it just ends up in a little bit of wasted time and friction trying to do it with the minimum spec.
Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.
Issue Details
Today, if I go to the dotnet/runtime repository to create a Codespace with the default configuration from the Code button:
This will create a codespaces with 2 cores and 4 GB of RAM. Even with a pre-built container, this offers a somewhat rough experience. Between the VS Code and server-side extensions using some resources, running ./dotnet.sh test src/libraries/System.Security.Cryptography/tests will OOM.
While it would be nice if things worked in this configuration for folks that want to use the lowest possible billing rate, the frequent OOMs I encountered while using this configuration make me think we need to set a floor on the Codespaces configuration.
You can do this with the hostRequirements section in .devcontainer/devcontainer.json. I am proposing we add this:
Folks can always change the specs after they create the codespaces, but it just ends up in a little bit of wasted time and friction trying to do it with the minimum spec.
Developing in dotnet/runtime with a 2-core / 4GB ram machine doesn't work very well. Add a minimum of 4-core machine to the devcontainer spec.
Fixdotnet#75680
Today, if I go to the
dotnet/runtime
repository to create a Codespace with the default configuration from the Code button (without clicking the chevron):This will create a codespaces with 2 cores and 4 GB of RAM. Even with a pre-built container, this offers a somewhat rough experience. Between the VS Code and server-side extensions using some resources, running
./dotnet.sh test src/libraries/System.Security.Cryptography/tests
will OOM.While it would be nice if things worked in this configuration for folks that want to use the lowest possible billing rate, the frequent OOMs I encountered while using this configuration make me think we need to set a floor on the Codespaces configuration.
You can do this with the
hostRequirements
section in.devcontainer/devcontainer.json
. I am proposing we add this:Folks can always change the specs after they create the codespaces, but it just ends up in a little bit of wasted time and friction trying to do it with the minimum spec.
Documentation on is available on our docs.
/cc @eerhardt
The text was updated successfully, but these errors were encountered: