Create copilot-setup-steps.yml

[CarnaViire]

Based on copilot-setup-steps.yml from dotnet/aspire and dotnet/aspnetcore.

Script args based on

runtime/eng/pipelines/common/templates/runtimes/send-to-helix-inner-step.yml

Line 18 in 28e603e

- script: $(Build.SourcesDirectory)/eng/common/msbuild.sh --restore --ci --warnaserror false ${{ parameters.sendParams }}

Expected to help with the Firewall warnings over pkgs.dev.azure.com on Copilot PRs (e.g. #115826)

[Copilot]

Pull Request Overview

This PR creates a new GitHub Actions workflow file for running Copilot setup steps. It defines a new job named "copilot-setup-steps" which checks out the repository code and then runs a build script to restore the solution.

• Added a new workflow file (.github/workflows/copilot-setup-steps.yml)
• Configured the job to run on ubuntu-latest with proper permissions and setup steps

[stephentoub]

Expected to help with the Firewall warnings over pkgs.dev.azure.com on Copilot PRs (e.g. #115826)

Should we also add the relevant endpoints to the firewall allow list?

[danmoseley]

Should we also add the relevant endpoints to the firewall allow list?

We can, but if this makes that unnecessary, its nice to keep the network isolation?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[stephentoub]

if this makes that unnecessary

Does it? I very frequently see builds trying to do partial restores even after I've done full builds.

[danmoseley]

Does it? I very frequently see builds trying to do partial restores even after I've done full builds.

Then it will be necessary as well yeah.

[ericstj]

How does this get updated?

[ericstj]

I guess we have other usages https://github.com/search?q=repo%3Adotnet%2Fruntime%20actions%2Fcheckout%40&type=code. Consider using a tag if that's better.

[ericstj]

Thinking aloud here - would it also help to set some things in the environment so that it would use the dotnet that it pulled down on the path? I'm not sure what sort of resources the agent will be using, but we should try to set it up for local-development as close as possible. How do we see / measure how good these steps are working for the agent? Can we see it try them and then see how successful it is at doing things?

[danmoseley]

it seems to successfully know to go to the root of the repo and run 'build.sh' or whatever the onboarding instructions say.

But, if you add a .github\copilot-instructions.md you can be explicit about how it should do incremental subtree builds and how to run tests too.

[ericstj]

Yeah, I think putting dotnet on the path and including some instructions for building individual projects, testing individual projects might be a good idea since I expect the agent is actually doing these things so giving it the quicker inner-loops like real devs use should make it more efficient.

[CarnaViire]

I agree it's a good idea to add some specific instructions. I'll try it out in a separate PR.

[danmoseley]

I'm not sure it technically even needs this step, since runtime can be built from a single entry-point. My understanding of this workflow is to help steer it towards the right actions (acquiring pre-requisites for example and setting up the env). Starting with a restore isn't a bad thing, but I'm not sure it's not necessar

@ericstj not sure whether you're aware based on this comment but by default the agent itself is completely firewalled. The idea is that this build step will pull things down so that subsequent builds succeed. They're talking about things like caching the built tree, etc eventually. Of course, you can also open the firewall selectively.

[ViktorHofer]

If you want to restore more it needs to be told to include test projects, additionally I think there are some other projects that only build for things like mono / wasm etc. @ViktorHofer do we have a knob that says "restore for everything?" sort of like how allconfigurations used to work?

Not that I know of. I don't think it's possible to include the default subsets and also include the libs tests and other test subsets without listing them explicitly. The subset infrastructure in runtime isn't great. It also became extremely complex over the years.

FWIW I would probably add /p:BuildAllConfigurations=true /p:DotNetBuildAllRuntimePacks=true here to make sure that all libraries TFMs and all runtime packs projects are restored.

[ericstj]

I'm not sure it technically even needs this step, since runtime can be built from a single entry-point. My understanding of this workflow is to help steer it towards the right actions (acquiring pre-requisites for example and setting up the env). Starting with a restore isn't a bad thing, but I'm not sure it's not necessar

@ericstj not sure whether you're aware based on this comment but by default the agent itself is completely firewalled. The idea is that this build step will pull things down so that subsequent builds succeed. They're talking about things like caching the built tree, etc eventually. Of course, you can also open the firewall selectively.

I see, that makes sense. I see that here https://docs.github.com/en/copilot/customizing-copilot/customizing-or-disabling-the-firewall-for-copilot-coding-agent. Seems like that should be mentioned in the main article since that seems to be the motivating factor behind adding these.

[CarnaViire]

/ba-g copilot infra-only change

[CarnaViire]

Good news: this setup actually helped with restore (at least for the libs).

Bad news: it is insistent on using dotnet build ./src/libraries/....csproj instead of build.sh ..., so the build still fails because clr should have been built first 🥲

Maybe .github\copilot-instructions.md will be able to help with that.

[ericstj]

Yeah that should help. We might also want to put dotnet on the path so that it can directly build projects like that. I think that should make it more effective rather than doing a full build from the root every time.

[ViktorHofer]

We might also want to put dotnet on the path so that it can directly build projects like that

We should use the new global.json paths feature: https://learn.microsoft.com/en-us/dotnet/core/tools/global-json#paths. So that the resolution of the desired .NET SDK is handled by the host. It still needs to be acquired of course which is handled by the eng/common scripts and a globally installed one would need to be available.