Keep local validation fast enough for iterative agent use
- Dominant language
- C#
- Stars
- 3.2k
- Forks
- 1.3k
- PR merge metrics
- PR metrics pending
Description
## Problem
The full local `dotnet/sdk` build is too slow and unreliable for an iterative agent edit/validate loop.
A typical agent needs to:
1. Change product source.
2. Update the assembled SDK under `artifacts/bin/redist//dotnet`.
3. Run the smallest relevant test.
4. Repeat as necessary.
Project-level compilation is already incremental, but invoking the repository build/redist pipeline can still perform broad or unconditional work (see https://github.com/dotnet/sdk/issues/48070). This makes agents either wait for a full build or implement unsafe shortcuts such as manually copying selected assemblies.
A prototype that mapped changed paths to projects and copied allowlisted outputs demonstrated that fast validation is possible, but it duplicated dependency and layout knowledge outside MSBuild. The preferred direction is to make the normal MSBuild/redist build sufficiently incremental instead.
Focused test execution is the other half of the validation loop. Rebuilding the SDK quickly is not enough if agents then run an unnecessarily broad test suite, invoke the wrong test platform, or test against stale product output.
The repository already has mechanisms for selecting and running focused tests:
- `test/ConditionalTests.props` maps change areas to relevant test projects.
- The `targeted-test` workflow selects the smallest applicable project and filter.
## Proposed Direction
Prefer improving the existing MSBuild graph over maintaining a separate change-to-output mapping system.
Any orchestration should be limited to invoking MSBuild and selecting tests; it should not duplicate the product dependency graph or hardcode shipped output paths.
The desired workflow should compose these existing capabilities:
1. Run an incremental MSBuild operation that leaves the redist SDK current.
2. Select the smallest test project and class or method that covers the changed behavior.
3. Build that test project only when its inputs changed.
4. Run the focused test against the updated redist SDK.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.