Add initial codespaces support for dotnet/runtime #59723
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| # See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.192.0/containers/dotnet/.devcontainer/base.Dockerfile | ||
|
|
||
| # [Choice] .NET version: 5.0, 3.1, 2.1 | ||
| ARG VARIANT="5.0" | ||
| FROM mcr.microsoft.com/vscode/devcontainers/dotnet:0-${VARIANT} | ||
|
|
||
| # Set up machine requirements to build the repo | ||
| RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \ | ||
| && apt-get -y install --no-install-recommends cmake llvm-9 clang-9 \ | ||
| build-essential python curl git lldb-6.0 liblldb-6.0-dev \ | ||
| libunwind8 libunwind8-dev gettext libicu-dev liblttng-ust-dev \ | ||
| libssl-dev libnuma-dev libkrb5-dev zlib1g-dev ninja-build |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| // For format details, see https://aka.ms/devcontainer.json. For config options, see the README at: | ||
| // https://github.com/microsoft/vscode-dev-containers/tree/v0.192.0/containers/dotnet | ||
| { | ||
| "name": "C# (.NET)", | ||
| "build": { | ||
| "dockerfile": "Dockerfile", | ||
| "args": { | ||
| // Update 'VARIANT' to pick a .NET Core version: 2.1, 3.1, 5.0 | ||
| "VARIANT": "5.0", | ||
| } | ||
| }, | ||
|
|
||
| "settings": { | ||
| // Loading projects on demand is better for larger codebases | ||
| "omnisharp.enableMsBuildLoadProjectsOnDemand": true | ||
| }, | ||
|
|
||
| // Add the IDs of extensions you want installed when the container is created. | ||
| "extensions": [ | ||
| "ms-dotnettools.csharp" | ||
| ], | ||
|
|
||
| // Use 'onCreateCommand' to run pre-build commands inside the codespace | ||
| "onCreateCommand": "${containerWorkspaceFolder}/.devcontainer/scripts/onCreateCommand.sh", | ||
|
|
||
| // Add the locally installed dotnet to the path to ensure that it is activated | ||
| // This allows developers to just use 'dotnet build' on the command-line, and the local dotnet version will be used. | ||
| "remoteEnv": { | ||
| "PATH": "${containerWorkspaceFolder}/.dotnet:${containerEnv:PATH}", | ||
eerhardt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| "DOTNET_MULTILEVEL_LOOKUP": "0" | ||
| }, | ||
|
|
||
| // Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root. | ||
| "remoteUser": "vscode" | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| #!/usr/bin/env bash | ||
|
|
||
| set -e | ||
|
|
||
| # prebuild the repo, so it is ready for development | ||
| ./build.sh libs+clr -rc Release | ||
|
There was a problem hiding this comment. @safern if we add If so it's probably worth adding as I'm assuming There was a problem hiding this comment. @danmoseley There was a problem hiding this comment. So I will be able to build and run an individual test library (it doesn't need libs.tests built?) There was a problem hiding this comment. Correct with the given setup you will be able to run, There was a problem hiding this comment. nit: you can also do just a There was a problem hiding this comment. This command is very CLR/Libraries team specific. Would it make sense to build the entire repo instead of just those two subsets? (including host and packs) There was a problem hiding this comment. Eric has a mail out asking whether there's a way to have multiple flavors of dev container. There was a problem hiding this comment. We can always add more to the build in the future, if this turns out to be valuable to more people. There was a problem hiding this comment. Sounds good. My hope is that in the future we can spend some time on optimizing the repo's root build (including all subsets but with just one selected runtime) which should make it a no-brainer to build the entire repo. More and more parts will be required over time anyway, i.e. we don't use the live built host today in libraries but we want to. Similar for other parts like the targeting pack produced in the "packs" subset. /braindump end |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| name: Create Codespaces Prebuild | ||
|
There was a problem hiding this comment. Whoa - is this what it looks like? Exciting! We might later add more to the build (eg libs.tests) if we're typically picking up a cached image. There was a problem hiding this comment. If the prebuild fails, how will we know? There was a problem hiding this comment.
yes.
It is a GitHub action. I would hope we can set up rules when it fails to notify someone. |
||
| on: | ||
| schedule: | ||
| # Run at 06:00 am UTC every day | ||
| - cron: '0 6 * * *' | ||
| workflow_dispatch: | ||
| jobs: | ||
| createPrebuild: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v2 | ||
| - uses: github/codespaces-precache@v1.0.1 | ||
| with: | ||
| regions: WestUs2 | ||
| sku_name: standardLinux32gb | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
|
There was a problem hiding this comment. What is this for? No token should be needed? There was a problem hiding this comment. There was a problem hiding this comment. Following that to https://docs.github.com/en/actions/security-guides/automatic-token-authentication#example-1-passing-the-github_token-as-an-input it suggests the default permissions are very broad and one can restrict eg But I don't grok how this relates to EXPERIMENTAL_CODESPACE_CACHE_TOKEN. If you believe we're "doing it right" here then that's fine with me. There was a problem hiding this comment. This is literally copied from the above doc (and I see the exact same in other repos). https://github.com/github/codespaces-precache#standard-template https://github.com/microsoft/vscode/blob/main/.github/workflows/create-codespaces-prebuild.yml https://github.com/rails/rails/blob/main/.github/workflows/codespaces.yml |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -279,7 +279,6 @@ Session.vim | |
|
|
||
| # Visual Studio Code | ||
| .vscode/ | ||
|
|
||
| # Private test configuration and binaries. | ||
| config.ps1 | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would a "postStartCommand" allow us to do something useful? If we could write a welcome message to the user's terminal, we could help get them started by displaying some common build commands, a link to a doc, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could link to a doc and also run
./build.sh --help?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What build commands or docs do you think are useful here?
Looking around, I don't see others doing this. Maybe it is something we can enable after the initial work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That output is way too verbose to be useful for a new contributor.
If anything here, I could imagine pointing to https://github.com/dotnet/runtime/blob/main/docs/workflow/README.md. Beyond that, I'm not sure of the value of dumping more things out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I only found a few examples: https://grep.app/search?current=3&q=postStartCommand&filter[path][0]=.devcontainer/ and didn't spot any that were simply dumping help.
I had in mind just writing a few lines welcoming folks and pointing them to the readme, and saying to type "./build.sh --help"
yes, no need to do it now unless you feel like it. Just trying to think about how to smooth the path after the dev container starts and they're wondering what to do next. that is, if it even is visible in the terminal. I'm guessing it is.