dotnet / dotnet/sdk

Keep local validation fast enough for iterative agent use

Open
#55,859 0 comments 0 reactions 1 assignee Claimed by @mthalman View on GitHub
untriaged
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.