dotnet-ado-patterns

extends

stages

jobs

steps

${{ if }}

${{ each }}

DotNetCoreCLI@2

Scope

• Template references with extends, stages, jobs, and steps keywords
• Variable groups and variable templates for centralized configuration
• Pipeline decorators for organization-wide policy injection
• Conditional insertion with ${{ if }} and ${{ each }} expressions
• Multi-stage pipelines (build, test, deploy)
• Pipeline triggers for CI, PR, and scheduled runs

Out of scope

• Starter CI templates -- see [skill:dotnet-add-ci]
• CLI release pipelines (tag-triggered build-package-release for CLI tools) -- see [skill:dotnet-cli-release-pipeline]
• ADO-unique features (environments, service connections, classic releases) -- see [skill:dotnet-ado-unique]
• Build/test specifics -- see [skill:dotnet-ado-build-test]
• Publishing pipelines -- see [skill:dotnet-ado-publish]
• GitHub Actions workflow patterns -- see [skill:dotnet-gha-patterns]

examples.md

Agent Gotchas

1. Template parameter types are enforced at compile time -- passing a string where

   type: boolean

   is expected causes a validation error before the pipeline runs; always match types exactly.

2. extends

   templates cannot be overridden -- callers cannot inject steps before or after the mandatory stages; this is by design for policy enforcement.
3. Variable group secrets are not available in template expressions --

   ${{ variables.mySecret }}

   resolves at compile time when secrets are not yet available; use

   $(mySecret)

   runtime syntax instead.

4. ${{ each }}

   iterates at compile time -- the loop generates YAML before the pipeline runs; runtime variables cannot be used as the iteration source.
5. CI and PR triggers are mutually exclusive with

   trigger: none

   and

   pr: none

   -- omitting both

   trigger

   and

   pr

   sections enables default CI triggering on all branches; explicitly set

   trigger: none

   to disable.
6. Path filters in triggers use repository root-relative paths -- do not prefix paths with

   /

   or

   ./

   ; use

   src/**

   not

   ./src/**

   .
7. Scheduled triggers always run on the default branch first -- the

   branches.include

   filter applies after the schedule fires; the schedule itself is only evaluated from the default branch YAML.
8. Pipeline resource triggers require the source pipeline name, not the YAML file path -- use the pipeline name as shown in ADO, not the

   azure-pipelines.yml

   file path.