Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Improve Copilot validation guidance for multi-target and shared-artifact builds

Open Beginner friendly
  • Is something wrong?
#69,588 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
developer-experience, documentation

Research direction

Start in .github/copilot-instructions.md under the ## Running tests section and review the existing area build guidance. Update the instructions to cover declared target frameworks, serialized validation for shared artifacts, targeted-first escalation, and reporting unvalidated boundaries. Done means the repository-specific guidance is clear without changing build scripts, CI, or target frameworks.

Written by the indexing model from the issue text.

Description

design-proposal

Summary

Improve .github/copilot-instructions.md with repository-specific validation guidance for multi-target projects, shared build artifacts, and targeted-versus-area validation.

Motivation and goals

A retrospective across recent dotnet/aspnetcore agent sessions found three recurring sources of avoidable validation friction:

  • A change was validated only on a modern target framework before CI found net472 compatibility failures (Enum.IsDefined<TEnum> and OperatingSystem.IsWindows/IsLinux) in #69584. Another recent Identity task encountered separate .NET Framework-specific SourceLink/MSBuild behavior.
  • Concurrent builds/tests that shared the repository artifacts tree produced transient file-lock and CS2012 failures. Serial execution, including /m:1 when necessary, passed immediately.
  • Broad area build scripts failed on unrelated prerequisites such as absent googletest sources, Blazor JavaScript/template packages, or other generated assets, while targeted project builds faithfully covered the changed managed surface.

The goal is to help Copilot agents choose validation that is complete across declared target frameworks, deterministic around shared outputs, and proportional to the changed surface.

In scope

  • Require inspection of TargetFrameworks and compilation of every declared target that is buildable in the current environment before opening or undrafting a pull request.
  • Prevent concurrent dotnet build/dotnet test invocations when project graphs share the repository artifacts tree, with serial /m:1 recovery guidance for shared-output locks.
  • Direct agents to begin with the smallest faithful project validation and escalate to area scripts when broader integration coverage is relevant.
  • Require explicit reporting of target frameworks or broader validation boundaries that could not be exercised.

Out of scope

  • Changing repository build scripts, target frameworks, CI configuration, or artifact layout.
  • Treating every broad-build failure as unrelated; agents must still determine whether the missing prerequisite is required by the changed behavior.
  • Adding a repository-wide rule for manually mapping long test lists to annotations. That caused a mistake in #69584, but the retrospective did not find recurrence in other recent sessions, so it is not yet supported as a durable repository instruction.
  • Changing the existing requirement to activate the repository .NET environment before running dotnet commands.

Risks / unknowns

  • “Every declared target” must remain qualified by what can be built in the current environment; otherwise agents may spend time attempting unsupported platform-specific targets.
  • Targeted validation must not become an excuse to skip required area-level or end-to-end coverage. The proposed wording explicitly requires escalation when broader integration coverage is relevant.
  • Some invocations may be safe in parallel when outputs are isolated. The guidance should prohibit only project graphs sharing the repository artifacts tree and allow verified isolated/no-build invocations.
  • The current instruction that says to use each area’s build.sh may appear to conflict with targeted-first validation. The wording should clarify validation order rather than remove area-script expectations.

Examples

Proposed additions under ## Running tests in .github/copilot-instructions.md:

* Start validation with the smallest project build/test that faithfully covers the changed surface, then escalate to the area build script when its broader integration coverage is required. If an area script fails only because an unrelated native submodule, generated asset, or package prerequisite is absent, record that boundary and continue with targeted project validation; do not repeatedly rerun or provision unrelated prerequisites unless the changed behavior depends on them.
* When a changed project declares multiple target frameworks, inspect its `TargetFrameworks` and compile every declared target that can be built in the current environment before opening or undrafting a pull request. A successful build or test run for only the newest target does not establish compatibility with `net4xx` or other declared targets; explicitly report any target that could not be validated.
* Do not run `dotnet build` or `dotnet test` concurrently for project graphs that share the repository artifacts tree. Run them sequentially, or use a verified isolated/no-build invocation; when a shared-output file lock occurs, retry the smallest targeted command serially (use `/m:1` for MSBuild when needed) before treating it as a product failure.

A typical agent workflow after this change would be:

  1. Inspect the changed project’s declared target frameworks.
  2. Build/test the smallest projects that faithfully cover the change, serializing invocations that share outputs.
  3. Compile every locally buildable declared target.
  4. Escalate to the area script when integration coverage is required.
  5. Report unsupported targets or unrelated prerequisite boundaries explicitly.
Dominant language
C#
Stars
38.5k
Forks
12.5k
Avg merge
2d 4h
Merged PRs (30d)
243

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/aspnetcore

All issues in dotnet/aspnetcore

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.