Add initial codespaces support for dotnet/runtime #59723

eerhardt · 2021-09-28T21:37:55Z

These are the initial scripts to configure Codespaces in the dotnet/runtime repo.

These settings allow for a successful ./build.sh libs+clr -rc Release. And then you can develop and test src\libraries projects.

ghost · 2021-09-28T21:38:06Z

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

These are the initial scripts to configure Codespaces in the dotnet/runtime repo.

These settings allow for a successful ./build.sh libs+clr -rc Release. And then you can develop and test src\libraries projects.

Author:	eerhardt
Assignees:	-
Labels:	`area-Infrastructure-libraries`
Milestone:	-

.devcontainer/scripts/postCreateCommand.sh

danmoseley · 2021-09-28T22:56:49Z

.devcontainer/devcontainer.json

+
+	// Use 'postCreateCommand' to run commands after the container is created.
+	"postCreateCommand": "bash -i ${containerWorkspaceFolder}/.devcontainer/scripts/postCreateCommand.sh",
+


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.

Maybe we could link to a doc and also run ./build.sh --help?

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?

also run ./build.sh --help?

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.

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.

danmoseley · 2021-09-28T23:43:05Z

.devcontainer/scripts/onCreateCommand.sh

+set -e
+
+# prebuild the repo, so it is ready for development
+./build.sh libs+clr -rc Release


@safern if we add +libs.pretest here, will that leave me in a state where I can walk up to any /tests folder and type dotnet build /t:build;test without any other prereqs?

If so it's probably worth adding as I'm assuming libs.pretest is fast.

@danmoseley libs.pretest is already part of the default subsets for libs, so no need to add it.

So I will be able to build and run an individual test library (it doesn't need libs.tests built?)

Correct with the given setup you will be able to run, dotnet build /t:test on a test project and it will work. libs.tests is not needed unless you want to run all tests or send to helix.

nit: you can also do just a dotnet test after a build.cmd/sh clr+libs, doesn't need to be dotnet build /t:test.

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)

Eric has a mail out asking whether there's a way to have multiple flavors of dev container.

We can always add more to the build in the future, if this turns out to be valuable to more people.

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

.devcontainer/devcontainer.json

stephentoub

Excited to try this out.

radical · 2021-09-29T00:51:04Z

Does it allow you have to more than one prebuild, like for different configs (eg. wasm :)?

eerhardt · 2021-09-29T01:52:25Z

Does it allow you have to more than one prebuild, like for different configs (eg. wasm :)?

That's a good question - I'm not sure. I was also thinking about coreclr devs who would potentially want a Debug build of coreclr and not a Release build. My thought there was that we could build for Debug as well, and have both Debug and Release configs built. But for mono, I'm not sure how to support that. I'll ask.

captainsafia

LGTM. Looking forward to seeing how the prebuilds roll out.

Another thing pending for me to add to the config for aspnetcore repo is a more helpful set of default extensions (XML Docs extension, EditorConfig extension, etc). Might be helpful to sort out a good standard set to use across the dotnet repos.

danmoseley · 2021-09-29T13:19:08Z

Might be helpful to sort out a good standard set to use across the dotnet repos.

Markdown too and maybe Git. Perhaps we can ask one of our full time VS Code users what they have installed.

danmoseley · 2021-09-29T15:19:20Z

.github/workflows/create-codespaces-prebuild.yml

@@ -0,0 +1,17 @@
+name: Create Codespaces Prebuild


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.

If the prebuild fails, how will we know?

is this what it looks like?

yes.

If the prebuild fails, how will we know?

It is a GitHub action. I would hope we can set up rules when it fails to notify someone.

https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications#github-actions-notification-options

danmoseley · 2021-09-29T15:19:45Z

.github/workflows/create-codespaces-prebuild.yml

+          regions: WestUs2
+          sku_name: standardLinux32gb
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}


What is this for? No token should be needed?

See https://github.com/github/codespaces-precache#environment-properties

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

permissions: contents: read

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.

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

name: precache codespace on: push: branches: - main 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 }}

https://github.com/microsoft/vscode/blob/main/.github/workflows/create-codespaces-prebuild.yml

https://github.com/rails/rails/blob/main/.github/workflows/codespaces.yml

danmoseley · 2021-09-29T15:20:18Z

.github/workflows/create-codespaces-prebuild.yml

@@ -0,0 +1,17 @@
+name: Create Codespaces Prebuild


If the prebuild fails, how will we know?

danmoseley · 2021-09-29T17:19:39Z

@tmds or @am11 just curious, do you see this button?

My assumption is that folks only get this if they either have an enterprise sub (eg., presumably all Microsoft employees do) or they joined the CodeSpaces beta. But I'd love to be wrong.

tmds · 2021-09-29T17:26:54Z

just curious, do you see this button?

No, it doesn't show up.

danmoseley · 2021-09-29T17:46:35Z

@eerhardt @captainsafia do you have experience with hosting codespaces containers locally? (the prebuilt ones we should now have every 6 am)

I see that VSCode does this: https://github.com/microsoft/vscode/tree/main/.devcontainer
That might be a path forward for folks not on the Beta.

eerhardt · 2021-09-29T17:48:01Z

I don't. If I'm going to use my local machine, I'm going to use it directly, and use Windows + Visual Studio.

danmoseley · 2021-09-29T17:52:59Z

For sure -- if you are a regular committer, you're going to either use your local machine or a CodeSpace.

I'm thinking about a casual contributor -- downloading a docker image with the repo already pulled down, prereqs installed and everything built, that could be a signficant improvement over setting it up themselves. CodeSpace would be even better, but as we've seen it's not available to most of them.

captainsafia · 2021-09-30T00:34:10Z

@eerhardt @captainsafia do you have experience with hosting codespaces containers locally? (the prebuilt ones we should now have every 6 am)

So I haven't tried this with prebuilt images but my patterns for working with dev containers locally have been:

Starting in a running Codespaces instance open the command prompt and use the Open in VS Code action to open the Codespace in VS Code. You'll need to have the GitHub Codespaces VSCode extension installed. Note: this is connecting your local VS Code client to a container running on a machine in the cloud somewhere.
Starting in local VS Code with Docker installed on your machine and the Remote Containers extension installed. In the VS Code command prompt, run Remote-Containers: Open Folder in Container to open the folder in a Docker container. This is connecting your local VS Code client to a container running on your machine.

I haven't been able to do something similar to the model you're proposing Dan unfortunately. :/

lewing · 2021-09-30T00:38:37Z

Does it allow you have to more than one prebuild, like for different configs (eg. wasm :)?

That's a good question - I'm not sure. I was also thinking about coreclr devs who would potentially want a Debug build of coreclr and not a Release build. My thought there was that we could build for Debug as well, and have both Debug and Release configs built. But for mono, I'm not sure how to support that. I'll ask.

We regularly build wasm using codespaces, we can provide some input

Add initial codespaces support for dotnet/runtime

bb23fd2

eerhardt requested review from captainsafia and danmoseley September 28, 2021 21:37

dotnet-issue-labeler bot added the area-Infrastructure-libraries label Sep 28, 2021

safern reviewed Sep 28, 2021

View reviewed changes

.devcontainer/scripts/postCreateCommand.sh Outdated Show resolved Hide resolved

danmoseley reviewed Sep 28, 2021

View reviewed changes

Enable codespaces-prebuild

e99c324

danmoseley reviewed Sep 28, 2021

View reviewed changes

.devcontainer/devcontainer.json Show resolved Hide resolved

stephentoub reviewed Sep 29, 2021

View reviewed changes

captainsafia reviewed Sep 29, 2021

View reviewed changes

danmoseley reviewed Sep 29, 2021

View reviewed changes

danmoseley approved these changes Sep 29, 2021

View reviewed changes

ViktorHofer approved these changes Sep 29, 2021

View reviewed changes

eerhardt merged commit 8e4c996 into dotnet:main Sep 29, 2021

eerhardt deleted the AddCodeSpaces branch September 29, 2021 16:41

ghost locked as resolved and limited conversation to collaborators Nov 3, 2021


		// Use 'postCreateCommand' to run commands after the container is created.
		"postCreateCommand": "bash -i ${containerWorkspaceFolder}/.devcontainer/scripts/postCreateCommand.sh",

Add initial codespaces support for dotnet/runtime #59723

Add initial codespaces support for dotnet/runtime #59723

Conversation

eerhardt commented Sep 28, 2021

ghost commented Sep 28, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephentoub left a comment

Choose a reason for hiding this comment

radical commented Sep 29, 2021

eerhardt commented Sep 29, 2021

captainsafia left a comment

Choose a reason for hiding this comment

danmoseley commented Sep 29, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eerhardt Sep 29, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danmoseley commented Sep 29, 2021

tmds commented Sep 29, 2021

danmoseley commented Sep 29, 2021

eerhardt commented Sep 29, 2021

danmoseley commented Sep 29, 2021

captainsafia commented Sep 30, 2021

lewing commented Sep 30, 2021 • edited Loading

eerhardt Sep 29, 2021 •

edited

Loading

lewing commented Sep 30, 2021 •

edited

Loading