Ci workflow

.NET CI Workflow

Purpose

Make .NET CI prove the same behavior maintainers care about locally.

The practical job is to choose SDK setup, restore/build/test commands, optional format/package checks, path filters, and matrix scope without making CI broader or noisier than the project needs.

When To Use

• Use this skill when adding or changing CI for a .NET repository.
• Use this skill when local validation and CI disagree.
• Use this skill when adding F# or C# projects to an existing CI workflow.
• Use this skill before package or release workflows depend on CI results.

Source Check

Use repo-local files, checked-out dependency sources, Dash MCP or Dash HTTP for installed docsets, and then official project documentation when Dash/local coverage is missing or stale:

• GitHub Actions and .NET
• Create a .NET test validation GitHub workflow
• actions/setup-dotnet
• dotnet restore documentation
• dotnet build documentation
• dotnet test documentation

CI Planning Workflow

1. Inspect local validation commands.
2. Inspect existing workflow files:

   rg --files .github/workflows -g '*.yml' -g '*.yaml'
   

3. Check SDK source:
   • global.json
   • workflow dotnet-version
   • repository docs
4. Decide job scope:
   • restore
   • build
   • test
   • format check
   • pack check
5. Decide matrix scope:
   • one OS for library CI unless cross-platform behavior matters
   • multiple OSes for filesystem, process, path, native dependency, or user-facing CLI differences
6. Keep local and CI commands aligned.

Baseline Command Order

Prefer a simple shape:

dotnet restore
dotnet build --configuration Release --no-restore
dotnet test --configuration Release --no-build

Add package validation only for package surfaces:

dotnet pack --configuration Release --no-build

Add formatting verification only when the repo has .editorconfig and expects it:

dotnet format --verify-no-changes

F# And C# Notes

For F#:

• make sure CI builds the projects that prove .fsproj ordering
• do not path-filter only **.cs when F# files exist

For C#:

• keep nullable/analyzer failures visible
• respect warnings-as-errors behavior already used by the repo

For mixed solutions:

• include **.fs, **.fsproj, **.cs, and **.csproj in path filters when filters are used
• run solution-level validation when project references cross language boundaries

Output Shape

Return:

1. CI scope: restore, build, test, format, pack.
2. SDK source: global.json, workflow version, or repo docs.
3. Matrix: OS and SDK versions.
4. Commands: local and CI command match.
5. Path filters: F#, C#, project, props, and workflow files.
6. Residual risk: what CI intentionally does not cover.

Guardrails

• Do not make CI publish packages unless the user asks for a release workflow.
• Do not filter out F# paths in a plugin that promises F# parity.
• Do not add large OS matrices without naming the cross-platform behavior they protect.
• Do not hide build warnings if the repo treats warnings as errors locally.
• Do not make CI commands differ from documented local validation without explaining why.