dotnet-add-ci
dotnet-add-ci
Add starter CI/CD workflows to an existing .NET project. Detects the hosting platform (GitHub Actions or Azure DevOps) and generates an appropriate starter workflow for build, test, and pack.
Scope
- Platform detection (GitHub Actions vs Azure DevOps)
- Starter build/test/pack workflow generation
- Basic CI workflow templates for .NET projects
Out of scope
- Advanced CI/CD patterns (reusable workflows, matrix builds, deployment) -- see [skill:dotnet-gha-patterns] and [skill:dotnet-ado-patterns]
Prerequisites: Run [skill:dotnet-version-detection] first to determine SDK version for the workflow. Run [skill:dotnet-project-analysis] to understand solution structure.
Cross-references: [skill:dotnet-project-structure] for build props layout, [skill:dotnet-scaffold-project] which generates the project structure these workflows build.
Platform Detection
Detect the CI platform from existing repo indicators:
| Indicator | Platform |
|---|---|
.github/ directory exists |
GitHub Actions |
azure-pipelines.yml exists |
Azure DevOps |
.github/workflows/ has YAML files |
GitHub Actions (already configured) |
| Neither | Ask the user which platform to target |
GitHub Actions Starter Workflow
Create .github/workflows/build.yml:
name: Build and Test
on:
push:
branches: [main]
pull_request:
branches: [main]
permissions:
contents: read
env:
DOTNET_NOLOGO: true
DOTNET_CLI_TELEMETRY_OPTOUT: true
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup .NET
uses: actions/setup-dotnet@v4
with:
global-json-file: global.json
- name: Restore
run: dotnet restore --locked-mode
- name: Build
run: dotnet build --no-restore -c Release
- name: Test
run: dotnet test --no-build -c Release --logger trx --results-directory TestResults
- name: Upload test results
uses: actions/upload-artifact@v4
if: always()
with:
name: test-results
path: TestResults/**/*.trx
Key Decisions Explained
global-json-file— uses the repo'sglobal.jsonto install the exact SDK version. If the project has noglobal.json, replace withdotnet-version: '10.0.x'(or the appropriate version)--locked-mode— ensurespackages.lock.jsonfiles are respected; fails if they're out of date. If the project doesn't use lock files, replace with plaindotnet restore-c Release— builds in Release mode soContinuousIntegrationBuildtakes effectpermissions: contents: read— principle of least privilege- Environment variables — suppress .NET CLI noise in logs
Adding NuGet Pack (Libraries)
For projects that publish to NuGet, add a pack step:
- name: Pack
run: dotnet pack --no-build -c Release -o artifacts
- name: Upload packages
uses: actions/upload-artifact@v4
with:
name: nuget-packages
path: artifacts/*.nupkg
Azure DevOps Starter Pipeline
Create azure-pipelines.yml at the repo root:
trigger:
branches:
include:
- main
pr:
branches:
include:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
DOTNET_NOLOGO: true
DOTNET_CLI_TELEMETRY_OPTOUT: true
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
buildConfiguration: 'Release'
steps:
- task: UseDotNet@2
displayName: 'Setup .NET SDK'
inputs:
useGlobalJson: true
- script: dotnet restore --locked-mode
displayName: 'Restore'
- script: dotnet build --no-restore -c $(buildConfiguration)
displayName: 'Build'
- task: DotNetCoreCLI@2
displayName: 'Test'
inputs:
command: 'test'
arguments: '--no-build -c $(buildConfiguration) --logger trx'
publishTestResults: true
Adding NuGet Pack (Libraries)
- script: dotnet pack --no-build -c $(buildConfiguration) -o $(Build.ArtifactStagingDirectory)
displayName: 'Pack'
- task: PublishBuildArtifacts@1
displayName: 'Publish NuGet packages'
inputs:
pathToPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'nuget-packages'
Adapting the Starter Workflow
Multi-TFM Projects
If the project multi-targets, the default workflow works without changes — dotnet build and dotnet test handle all TFMs automatically. No matrix is needed for the starter.
Windows-Only Projects (MAUI, WPF, WinForms)
Change the runner:
# GitHub Actions
runs-on: windows-latest
# Azure DevOps
pool:
vmImage: 'windows-latest'
Solution Filter
If the repo has multiple solutions or uses solution filters:
- name: Build
run: dotnet build MyApp.slnf --no-restore -c Release
Verification
After adding the workflow, verify locally:
# GitHub Actions — validate YAML syntax
# Install: gh extension install moritztomasi/gh-workflow-validator
gh workflow-validator .github/workflows/build.yml
# Or simply verify the build steps work locally
dotnet restore --locked-mode
dotnet build --no-restore -c Release
dotnet test --no-build -c Release
Push a branch and open a PR to trigger the workflow.
What's Next
This starter covers build-test-pack. For advanced scenarios, see the CI/CD depth skills:
- Reusable composite actions and workflow templates
- Matrix builds across OS/TFM combinations
- Deployment pipelines with environment gates
- NuGet publishing with signing
- Container image builds
- Code coverage reporting and enforcement
References
More from novotnyllc/dotnet-artisan
dotnet-ui
Builds .NET UI apps across Blazor (Server, WASM, Hybrid, Auto), MAUI (XAML, MVVM, Shell, Native AOT), Uno Platform (MVUX, Extensions, Toolkit), WPF (.NET 8+, Fluent theme), WinUI 3 (Windows App SDK, MSIX, Mica/Acrylic, adaptive layout), and WinForms (high-DPI, dark mode) with JS interop, accessibility (SemanticProperties, ARIA), localization (.resx, RTL), platform bindings (Java.Interop, ObjCRuntime), and framework selection. Spans 20 topic areas. Do not use for backend API design or CI/CD pipelines.
99dotnet-api
Builds ASP.NET Core APIs, EF Core data access, gRPC, SignalR, and backend services with middleware, security (OAuth, JWT, OWASP), resilience, messaging, OpenAPI, .NET Aspire, Semantic Kernel, HybridCache, YARP reverse proxy, output caching, Office documents (Excel, Word, PowerPoint), PDF, and architecture patterns. Spans 32 topic areas. Do not use for UI rendering patterns or CI/CD pipeline authoring.
90dotnet-testing
Defines .NET test strategy and implementation patterns across xUnit v3 (Facts, Theories, fixtures, IAsyncLifetime), integration testing (WebApplicationFactory, Testcontainers), Aspire testing (DistributedApplicationTestingBuilder), snapshot testing (Verify, scrubbing), Playwright E2E browser automation, BenchmarkDotNet microbenchmarks, code coverage (Coverlet), mutation testing (Stryker.NET), UI testing (page objects, selectors), and AOT WASM test compilation. Spans 13 topic areas. Do not use for production API architecture or CI workflow authoring.
86dotnet-advisor
Routes .NET/C# requests to the correct domain skill and loads coding standards as baseline for all code paths. Determines whether the task needs API, UI, testing, devops, tooling, or debugging guidance based on prompt analysis and project signals, then invokes skills in the right order. Always invoked after [skill:using-dotnet] detects .NET intent. Do not use for deep API, UI, testing, devops, tooling, or debugging implementation guidance.
60dotnet-debugging
Debugs Windows and Linux/macOS applications (native, .NET/CLR, mixed-mode) with WinDbg MCP (crash dumps, !analyze, !syncblk, !dlk, !runaway, !dumpheap, !gcroot, BSOD), dotnet-dump, lldb with SOS, createdump, and container diagnostics (Docker, Kubernetes). Hang/deadlock diagnosis, high CPU triage, memory leak investigation, kernel debugging, and dotnet-monitor for production. Spans 17 topic areas. Do not use for routine .NET SDK profiling, benchmark design, or CI test debugging.
57dotnet-devops
Configures .NET CI/CD pipelines (GitHub Actions with setup-dotnet, NuGet cache, reusable workflows; Azure DevOps with DotNetCoreCLI, templates, multi-stage), containerization (multi-stage Dockerfiles, Compose, rootless), packaging (NuGet authoring, source generators, MSIX signing), release management (NBGV, SemVer, changelogs, GitHub Releases), and observability (OpenTelemetry, health checks, structured logging, PII). Spans 18 topic areas. Do not use for application-layer API or UI implementation patterns.
52