microsoft / microsoft/aspire

Speed up Copilot cloud-agent startup and code review in Aspire

Open
#19,909 2 comments 0 reactions 0 assignees View on GitHub
area-copilot area-engineering-systems
Dominant language
C#
Stars
6.3k
Forks
991
Avg merge
2d 15h
Merged PRs (30d)
196

Description

[automated]

## Summary

Aspire's GitHub Copilot cloud-agent and code-review sessions perform substantial environment setup before useful work begins. We do not currently have a reliable per-step baseline, and code review inherits the full coding-agent setup even though recent reviews did not use the restored solution or invoke build tools.

The current `.github/workflows/copilot-setup-steps.yml` checks out the repository, installs `gh-aw`, restores the solution, installs Verify, configures `PATH`, installs .NET 10 and .NET 8, and prints SDK diagnostics. The `PATH` step is malformed YAML and does not add the intended directories independently.

#9626 previously reduced setup from approximately four minutes to two by moving from a 2-core to an 8-core runner; 16 cores was not worthwhile. #9710 replaced the setup-time build with restore-only and explicitly noted that firewall access would need to be investigated before builds and tests could run reliably from the agent session.

## Goal

Reduce time from task assignment or review request to useful agent work while preserving reliable restore, build, test, and representative AppHost execution from the agent session.

Keep the integrated firewall enabled and use narrowly scoped allowlist entries rather than broad access.

## Workstreams, ordered by effort-adjusted impact

| Priority | Workstream | Expected value | Dependency |
|---|---|---|---|
| 1 | #19906 | Fix setup correctness and make workflow changes automatically testable | None |
| 2 | #19907 | Stop code review from paying for coding-agent dependencies it does not use | None |
| 3 | #19908 | Determine what is required before setup-time restore can be removed | None |
| 4 | Defer or remove universal setup-time restore | Reduce coding-agent startup materially | Firewall rules applied and validated |
| 5 | Remove redundant setup tools and reduce globally enabled MCP servers | Reduce setup and initialization work | Usage data available |
| 6 | Move subsystem-specific review guidance from universal context into path-specific instructions and skills | Reduce review context while retaining quality | Review benchmark established |
| 7 | Evaluate a pre-warmed custom larger-runner image | Bake stable SDKs and tools when setup steps remain expensive | Simpler changes measured first |
| 8 | Evaluate ephemeral self-hosted runners | Maximum environment control | Only if hosted-runner options remain insufficient |

## Measurement protocol

For each performance-changing experiment:

1. Record at least five fresh baseline runs and five fresh post-change runs.
2. Record queue time, checkout time, each setup-step duration, total setup time, agent-ready time, and end-to-end completion or review time.
3. Report median, minimum, and maximum values.
4. Change one performance variable at a time.
5. Treat a median change below 15%, or a result within observed run-to-run variance, as inconclusive.
6. Measure behavior after the relevant workflow reaches the default branch. Copilot setup files on an unmerged branch do not provide a valid coding-agent startup comparison.
7. Do not use cloud-session `created_at` to `updated_at` timestamps as task duration; existing telemetry does not include the complete environment-setup interval.

For review changes, use the same representative pull-request set before and after the change and record both completion time and whether high-confidence findings were retained.

## Sequencing

These changes should be separate PRs and should normally target `main`, not form a stacked PR chain. Merge and measure each performance variable before landing the next one so improvements can be attributed to a specific change.

The first three child issues are independent and can be implemented or investigated concurrently. Workstreams 4-8 should not start until their listed prerequisites are available.

## Definition of done

- Copilot setup workflow changes run automatically on relevant pull requests and remain manually dispatchable.
- The intended tool and repository-local .NET directories are valid `PATH` entries.
- Code review has a dedicated minimal setup and no longer inherits unused restore and tool-install steps.
- Clean-cache restore, a representative build, targeted tests, and a representative Aspire project/AppHost run succeed from the coding-agent shell with the firewall enabled.
- Required firewall entries are documented, narrowly scoped, and mapped to the dependency or command that needs them.
- Setup-time restore is removed or deferred only after on-demand validation succeeds in at least three fresh sessions.
- Every retained optimization includes before-and-after measurements.
- At least one landed optimization produces a 15% or greater median improvement in the affected startup path without a material review-quality or validation regression.

Contributor guide

Open the contributing guide

Research direction

Start with .github/workflows/copilot-setup-steps.yml and the independent child issues #19906, #19907, and #19908. Run five fresh baseline and post-change sessions, recording the specified setup and completion timings. Done means relevant workflow changes are tested and dispatchable, review has minimal setup, validation succeeds with the firewall enabled, and a landed optimization shows the required measured improvement.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, yaml
Domain
ci-cd, cloud, devops, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.