* Debug
* Building steps logging.
* Chop up restore and clean cache in between
* Restore does not take as much space as codespaces setup files in "/workspaces/.codespaces".
* Try removing the biggest offender.
* Cannot see the impact of cleanup on the size check logs.
* Move setup code into post-create
* Pass arg to the script, otherwise nothing is triggered
* Move all commands up to restore to onCreate. Restore should be done after codespaces setup when occupied disc space drops.
* Fix: wasm does not have artifacts dir on writing to this file.
* This would work but is not 100% reliable - user can interact with the VM before the command finishes.
* Build subset by subset.
* Easy fix - requre bigger disc.
Adds a default configuration that comes with all the dependencies preinstalled, but not prebuilt. This reduces confusion if you don't use the "New with options..." dropdown when creating the Codespace since you'd just get a standard Ubuntu container then.
Also install a specific version of dotnet-serve.
Follow-up on #32451
Follow-up on #80074
In #43651, the "Windows" OS name was lowercased to achieve target frameworks with RIDs in them. At that time, the original plan was to lowercase all TargetOS values but that had to be cut because of resources. This PR finishes that and updates build systems, YML, markdowns and managed components.
To not break existing developer workflows, the passed-in -os value is automatically lower-cased in the script entry points and validated in the msbuild entry point.
* Split libraries and wasm devcontainers
Codespaces allows for monorepo support now. So we can have different pre-builds for different dev environments.
Creating a "libraries" pre-build and a "wasm" pre-build devcontainer.
* Move devcontainer files into separate folders
* Path up a directory to the Dockerfile
* Split the Dockerfile so it can be customized per devcontainer
* Update Codespaces docs
* Respond to PR feedback
* Use the new open devcontainers path.
* Use the GH CLI feature instead of installing it ourselves
* Set hostRequirements for Codespaces
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.
Fix#75680
With these changes, running the following in the Codespace will open the local browser to a page served from the codespace hosting the WASM sample:
```console
cd src/mono/sample/wasm/browser
make
make run-browser
```
* Set EMSDK_PATH in .devcontainer.json
We provision Emscripten as part of the devcontainer prebuild.
Set EMSDK_PATH to allow rebuilding the wasm runtime to work without any additional ceremony
* Install dotnet-serve into .dotnet-tools-global
* [wasm] Don't try to open browser if running in Codespaces
* .devcontainer: add global tools dir to PATH
* .devcontainer: forward port 8000
This enables running the mono wasm samples in the local browser:
* [wasm] samples: also check for dotnet-serve on the path
On Codespaces we install dotnet-serve on the PATH but not where `dotnet tool list` can see it
* remove onAutoForward: notify - it's the default
* Adjust the path of v8 depends if running in a dev container
* Check if we're running in any Docker container, not just Codespaces
Co-authored-by: Fan Yang <52458914+fanyang-mono@users.noreply.github.com>
* Add instructions for using Codespaces
* Automate resetting the HEAD to the same commit ID used to build the pre-built container
* - Add notes about testing changes.
- Add 4-core machines
* Revert 4-core change since prebuild doesn't support multiple sku_names.
- mark onCreateCommand.sh as executable
- add more regions so users outside of West US can take advantage of prebuilt codespaces
- use v1-stable version, as recommended by docs
- use faster machines for dev productivity
