Change:
## Development Container <del> This repository includes a Visual Studio Code Remote - Containers / Codespaces development container. You can open it using the **Remote-Containers: Open Repository in Container...** from the [Remote - Containers](https://aka.ms/vscode-remote/download/containers) extension or by referencing the repository Git URL when creating a cloud-based environment using the [Visual Studio Codespaces](https://aka.ms/vscs-ext-vscode) extension. See the [development container README](.devcontainer/README.md) for more details on its use. </del> <ins> This repository includes a Visual Studio Code Remote - Containers / Codespaces development container. - For [Remote - Containers](https://aka.ms/vscode-remote/download/containers), use the **Remote-Containers: Open Repository in Container...** command which creates a Docker volume for better disk I/O on macOS and Windows. - For Codespaces, install the [Visual Studio Codespaces](https://aka.ms/vscs-ext-vscode) extension in VS Code, and use the **Codespaces: Create New Codespace** command. Docker / the Codespace should have at least **4 Cores and 6 GB of RAM (8 GB recommended)** to run full build. See the [development container README](.devcontainer/README.md) for more information. </ins> ## Code of Conduct

Discussion:
Testing I don't have a linux dev setup so I figured running smoke tests on linux is a good scenario for our own dev container. However, I failed a few times and eventually gave up enough resources. the readme explains this but not clear enough, e.g you cannot run without tweak the docker settings issues, e.g I have seen this after compiling and bundling for 20minutes <img width="711" alt="Screenshot 2020-06-30 at 11 06 32" src="https://user-"failure to run the smoke test (see below)
did you Open the VS Code repository into Volume?
Yeah breaking this down: looks like was getting used with some of the commands. This can cause folders that were created to be locked to root rather than the current user in the container. That could cause the permission issue. Erich mentioned, using the open reop in container option will dramatically speed things up on macOS and Windows (with the Hyper-V engine) and RAM and CPU need to be increased - I can make the guidance there even stronger. FWIW - I saw 6 mins for and 8 mins for w/4 cores and 8GB of RAM allocated on a 2015 MBP w/16 GB RAM and Sophos AV running. Note that compiling native modules during and max out CPU at certain points and hit ~7.12GB of RAM, so it's undoubtedly getting resource constrained at times. tests did fail - but it looks to me like some sort of bug in the test code. I don't know the test code - but I wonder looking at the logs if the wrong folder is getting created. In the log: And then later... Should test data have been to instead of or vice versa?
Nope. Tho, to my understanding that helps with IO. That's a nice boost but the blocker is that 2GB of RAM aren't enough to compile vscode, the compiler will simply crash at one point. Yeah, I ended up running the build (gulp vscode-linux-x64) with sudo because it failed with permission trouble before. Then I ran the tests as sudo because I was worries about exactly the issues that a normal user cannot access sudo-folders. I don't know the code either but I assume that it works ;-)
Yeah, totally agree there. Making sure the long build times weren't something else.

Can make that much more visible in the READMEs. Strange, yeah I haven't been able to repro that. Debugging a bit it seems like this other path is the handle for the driver. It seems to get past spawning Code and then fails connecting and gives up after 50 tries. Not sure yet why it's failing when does not.
On top of that, I was thinking to add a message to the build script (independent of dev containers) that checks that there is enough RAM to proceed.
Good idea. I also found the problem. Chrome sandboxing doesn't work in containers. So, the test needs to have passed in. After that it works though there's 4 failed tests (unknown if this is something container related). Here's the update. In : EDIT: I also found that you really need 6GB to do the smoke test. Even 4 isn't quite enough, so I can bump up that recommendation.
Even better, it looks like the problem is the default settings. This appears to resolve it in : I think you do have to chown to root and set permissions like you would normally in Linux. I'll play a bit more, but it took a while to figure out since the error was hidden. Now it's just a question of what the best solution is.