Review this CI pipeline that builds, tests and publishes a .NET 10 service with the dotnet CLI and dotnet format. What would you change and why?

1. The guarantees a pipeline should give

Review a pipeline against what it promises, not how the YAML looks:

2. What each step consumes and produces

 checkout
    |
 setup-dotnet (global.json)              -> exact SDK, e.g. 10.0.1xx
    |
 dotnet tool restore                     -> pinned local tools
    |
 dotnet restore --locked-mode            -> obj/project.assets.json
    |                                       fails with NU1004 if a lock file
    |                                       is out of date
 dotnet format --verify-no-changes       -> non-zero exit on any drift
    |  --no-restore                          (reads the restore output)
 dotnet build -c Release --no-restore    -> bin/Release/net10.0/*
    |
 dotnet test -c Release --no-build       -> TestResults/*.trx, coverage
    |
 dotnet publish -c Release --no-build    -> out/  (the same binaries)
    |
 upload artefact (+ test results with if: always())

Each --no-restore and --no-build removes an implicit step. Without them, build restores again, test builds and restores again, and publish builds a third time, which is slower and means the published files are not the ones the tests ran against.

3. The review, line by line

4. dotnet format in detail

dotnet format ships in the .NET SDK. It reads .editorconfig and the project's analyser settings, so it needs a restored project.

Useful options:

Why exit codes matter

A CI step fails only when its command returns a non-zero exit code. Plain dotnet format returns success after it has changed files, so the pipeline goes green and the fixes disappear with the agent. With --verify-no-changes it edits nothing and exits non-zero when any file would change, so the step fails and the log names each file and rule.

Rolling it out to an existing repo

1. Agree the .editorconfig rules and their severities.
2. Run dotnet format once and commit the result as a single "format only" commit.
3. Add that commit's hash to .git-blame-ignore-revs so git blame skips it.
4. Turn on --verify-no-changes in CI and make it a required check.
5. Offer developers the same command as a pre-commit hook or IDE "format on save".

5. --no-build on publish: when it works

dotnet publish --no-build copies the existing build output, so the build must match:

If you publish for a RID, either build and test with that RID too, or accept that publish does its own build and that tests ran against the portable build. Make that trade-off on purpose.

6. Locked restore

<!-- Directory.Build.props -->
<Project>
  <PropertyGroup>
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
  </PropertyGroup>
</Project>

• Each project then gets a packages.lock.json recording the exact resolved version and content hash of every direct and transitive package.
• Developers commit the lock files. When they change a package reference, a normal restore updates the file.
• CI runs dotnet restore --locked-mode, which fails (NU1004) instead of silently resolving something different.
• Key the NuGet cache on hashFiles('**/packages.lock.json'), so the cache changes exactly when dependencies change.
• Since .NET 10, NuGet audit checks transitive packages by default, so restore warns about known vulnerable packages anywhere in the graph. Decide whether those warnings fail the build.

7. Tests and coverage

dotnet test -c Release --no-build \
  --logger trx --results-directory TestResults \
  --collect "XPlat Code Coverage"

• Upload TestResults with if: always() (GitHub Actions) or condition: succeededOrFailed() (Azure Pipelines), because you need the results most when tests fail.
• Publish the TRX to the PR (for example with a test reporter action, or PublishTestResults@2 in Azure Pipelines) so developers see failing test names without reading logs.
• Add --blame-hang-timeout 10m so a hung test produces a dump instead of a silent timeout.
• If the repo uses Microsoft.Testing.Platform ("test": { "runner": "Microsoft.Testing.Platform" } in global.json on .NET 10), the options differ, for example --report-trx and --coverage. Check which runner the repo uses before copying flags.

8. Performance

9. Security

• Set permissions: contents: read at the workflow level. Give packages: write or id-token: write only to the job that needs it.
• Pin third-party actions to a full commit SHA in sensitive repos, with a comment showing the version, and let Dependabot update them.
• Don't expose secrets to pull_request runs from forks. Never use pull_request_target to build untrusted code.
• Use package source mapping in nuget.config so each package can only come from its intended feed.
• Generate an SBOM and sign or attest the artefact if your organisation requires supply-chain evidence.

10. .NET 11 awareness

The .NET 11 SDK is due in November 2026 as a standard-term (STS) release and is at the preview and release-candidate stage now. It keeps the same restore, build, test, publish and format commands. Expect more projects to move to Microsoft.Testing.Platform, which changes dotnet test options. Keep production pipelines on the .NET 10 SDK through global.json, and trial .NET 11 in a separate branch or job.

11. Try it yourself

1. Create a solution with a class library and a test project. Add an .editorconfig with csharp_style_namespace_declarations = file_scoped:warning.
2. Write a class with a block-scoped namespace.
3. Run dotnet format style --verify-no-changes, then echo $?. Note the non-zero exit code.
4. Run dotnet format style and look at the diff.
5. Enable RestorePackagesWithLockFile, restore, and commit the lock file. Change a package version in the project file without restoring, then run dotnet restore --locked-mode and read the NU1004 error.
6. Time dotnet build && dotnet test && dotnet publish against dotnet build -c Release && dotnet test -c Release --no-build && dotnet publish -c Release --no-build.
7. Run dotnet publish -c Release -r linux-x64 --no-build after a portable build, and see why the RID must match.

name: ci
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      DOTNET_NOLOGO: true
      NUGET_PACKAGES: ${{ github.workspace }}/.nuget/packages
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          global-json-file: global.json

      - uses: actions/cache@v4
        with:
          path: ${{ github.workspace }}/.nuget/packages
          key: nuget-${{ runner.os }}-${{ hashFiles('**/packages.lock.json') }}

      - run: dotnet tool restore
      - run: dotnet restore --locked-mode
      - run: dotnet format --verify-no-changes --no-restore --severity warn
      - run: dotnet build -c Release --no-restore
      - run: >
          dotnet test -c Release --no-build
          --logger trx --results-directory TestResults
          --collect "XPlat Code Coverage"
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: test-results
          path: TestResults
      - run: dotnet publish src/Orders.Api -c Release --no-build -o out
      - uses: actions/upload-artifact@v4
        with:
          name: api
          path: out

<!-- Directory.Build.props: enable lock files repo-wide -->
<Project>
  <PropertyGroup>
    <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
  </PropertyGroup>
</Project>