Speed up Copilot cloud-agent startup and code review in Aspire
- 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
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