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