Azdo Internal

Aspire AzDO Internal Pipelines

Select the pipeline that actually consumes the change, then use that definition consistently for preflight, queueing, and monitoring.

Overview

The Aspire repo (microsoft/aspire on GitHub) has an internal mirror at dnceng/internal/_git/microsoft-aspire on Azure DevOps. The official build produces packages, native CLI binaries, and installers. Source indexing runs in a separate pipeline; it is not a source-build distribution pipeline.

Loading this skill is not permission to push, queue, cancel, or publish. Perform those actions only within the user's requested scope. Public / Helix tests are out of scope; see docs/ci/azdo-public-pipeline.md.

For the validation process (baseline, iteration, contributor-branch limits, and regression evidence), follow Track B of the CI infrastructure testing guide. The mechanics below support that process.

Shell note (Windows). Examples use bash; use Git Bash on Windows or translate the shell glue to pwsh (VAR=value becomes $VAR = 'value'; VAR=$(command) becomes $VAR = command). az, git, and gh are cross-platform. Disable git pagers with git --no-pager.

Key Details

Select the pipeline

Use 1602 for official-build changes and 1693 for indexing changes; shared inputs can require both. Do not substitute a green 1602 build for indexing validation: eng/pipelines/azure-pipelines.yml sets enableSourceIndex: false. Set the selected definition below, complete the prerequisites, then confirm its live name, repository, and YAML before queueing.

PIPELINE_ID=1602 # Set to 1693 for source indexing, or a discovered definition.

After preflight, confirm the definition:

az pipelines list --organization https://dev.azure.com/dnceng --project internal \
  --query "[?contains(name,'aspire')].{name:name,id:id}" -o table
az pipelines show --id "$PIPELINE_ID" --organization https://dev.azure.com/dnceng --project internal \
  --query '{id:id,name:name,repository:repository.name,yaml:process.yamlFilename}' -o json

Prerequisites

Before triggering or querying builds, confirm the environment is set up. Fail early if any of these are missing rather than emitting commands that will error:

# 1. Azure CLI present
az version

# 2. The azure-devops extension (provides `az pipelines` / `az devops`)
az extension show --name azure-devops

# 3. Access to the internal project (interactive login or AZURE_DEVOPS_EXT_PAT)
az devops project show --project internal --organization https://dev.azure.com/dnceng

Stop at a failed prerequisite. Install a missing azure-devops extension with az extension add --name azure-devops only when needed and permitted. A 401/403, TF400813, or an authentication prompt means stop before pushing or queueing; request an authorized maintainer run or report offline validation as incomplete. Never print credentials or loop on auth errors.

How to Push to the Internal Repo

The internal AzDO repo mirrors GitHub. Discover the remote with git --no-pager remote -v and match its URL to dnceng/internal/_git/microsoft-aspire; check read access with git --no-pager ls-remote --heads INTERNAL_REMOTE before pushing. Read access does not establish push permission. To push a branch for a manual build:

# Push your local branch to the internal remote (see "Git Remote Name" above to find yours)
git --no-pager push INTERNAL_REMOTE <local-branch>:<remote-branch-name>

# Example (use your own alias as the branch prefix):
git --no-pager push INTERNAL_REMOTE fix-azdo-pr-build:<your-alias>/fix-azdo-pr-build

If no remote points at the internal repo yet, add one (pick any name you like):

git --no-pager remote add INTERNAL_REMOTE https://dnceng@dev.azure.com/dnceng/internal/_git/microsoft-aspire

Branch rules (important). Push validation changes only to personal branches, e.g. <your-alias>/<branch>. The internal mirror enforces branch policies:

• main and release/* are policy-gated — direct/force pushes are rejected (they require a PR), so don't use them as your scratch validation branch.
• Inspect branch-control checks when a run is blocked. A personal branch does not bypass service-connection checks or job conditions. In particular, indexing defaults to main only (see below).

Triggering the Pipeline

Reconcile existing runs before queueing

Set BRANCH to the remote branch and COMMIT to the pushed commit. The example assumes you pushed the current HEAD; otherwise use the actual pushed revision. List runs for the selected definition and branch, including their revisions:

BRANCH='<your-alias>/<branch>'
COMMIT=$(git --no-pager rev-parse HEAD)
az pipelines build list --definition-ids "$PIPELINE_ID" \
  --organization https://dev.azure.com/dnceng --project internal --branch "refs/heads/$BRANCH" \
  --top 10 \
  --query '[].{id:id,status:status,result:result,commit:sourceVersion,reason:reason}' -o json

Inspect the selected YAML's trigger: and pr: filters. Pushing may auto-queue the official build for a matching branch; personal branches are not automatically included. Source indexing has trigger: none and pr: none, so pushing alone does not queue 1693.

Reuse a queued/running run only when its definition, branch, commit, and relevant parameters match the intended validation. Do not cancel unrelated work on the same branch. Cancel only confirmed superseded runs belonging to this task, after checking az pipelines build cancel --help for the installed CLI:

az pipelines build cancel --build-id <SUPERSEDED_BUILD_ID> \
  --organization https://dev.azure.com/dnceng --project internal

If that command is unavailable, use the build UI.

Via Azure CLI (when no matching run exists)

# Trigger a build on a specific branch
az pipelines run \
  --id "$PIPELINE_ID" \
  --organization https://dev.azure.com/dnceng \
  --project internal \
  --branch "$BRANCH" \
  --commit-id "$COMMIT"

The command returns JSON including id (build ID) and url. Record the definition, branch, commit, parameters, and build ID. --commit-id pins the intended revision if the remote branch advances; omit it only when the request is explicitly to build the latest remote tip. Read runtime parameters from the selected YAML and pass any required overrides with --parameters name=value.

If queueing times out, do not retry immediately. The server may already have accepted the request. Repeat the definition/branch/revision lookup above and inspect candidate runs. Retry only after confirming no matching run was queued; if the lookup itself fails, stop rather than risk a duplicate.

Pipeline structure

Don't rely on a snapshot here — the stages, job conditions, and variables change. Read the current definition from the repo:

• eng/pipelines/azure-pipelines.yml — stages, jobs, gating conditions
• eng/pipelines/azure-pipelines-source-index.yml — indexing schedule and job parameters
• eng/pipelines/templates/ — per-job step templates
• eng/pipelines/scripts/ — the scripts those steps run

To see why a stage/job ran or was skipped, read the build timeline and logs, not just the headline status. Follow template parameters into eng/common/core-templates/ when a condition is inherited.

Monitoring a Build

Build Results URL

https://dev.azure.com/dnceng/internal/_build/results?buildId=<BUILD_ID>

Via Azure CLI

# Check build details, including definition, sourceBranch, sourceVersion, status, and result
az pipelines build show \
  --id <BUILD_ID> \
  --organization https://dev.azure.com/dnceng \
  --project internal

# List recent builds for the selected definition (for example, to find a baseline)
az pipelines build list \
  --definition-ids "$PIPELINE_ID" \
  --organization https://dev.azure.com/dnceng --project internal \
  --top 5

# List recent builds for the selected definition and branch
az pipelines build list \
  --definition-ids "$PIPELINE_ID" \
  --organization https://dev.azure.com/dnceng --project internal \
  --branch "refs/heads/$BRANCH" \
  --top 5

Read the timeline, task logs, and artifacts

az devops invoke --area build --resource Timeline \
  --route-parameters project=internal buildId=<BUILD_ID> \
  --org https://dev.azure.com/dnceng --api-version 7.1 \
  --query 'records[].{name:name,type:type,state:state,result:result,log:log.id,issues:issues}' -o json

partiallySucceeded can reflect SDL warnings, but no failed records is not proof of validation. Inspect warning-bearing, canceled, and skipped records; verify the intended job actually ran and its observable output matches the change. Report security findings and unreachable paths explicitly instead of dismissing all SDL warnings.

Retrieve the task's log.id from the timeline. Use a new output path under the session artifacts directory; --out-file must not already exist:

az devops invoke --area build --resource logs \
  --route-parameters project=internal buildId=<BUILD_ID> logId=<LOG_ID> \
  --org https://dev.azure.com/dnceng --api-version 7.1 --accept-media-type text/plain \
  --out-file <NEW_LOG_PATH>

az pipelines runs artifact list --run-id <BUILD_ID> \
  --org https://dev.azure.com/dnceng --project internal \
  --query '[].{name:name,type:resource.type}' -o json

az pipelines runs artifact download --run-id <BUILD_ID> \
  --org https://dev.azure.com/dnceng --project internal \
  --artifact-name <ARTIFACT_NAME_FROM_LIST> --path <DOWNLOAD_DIRECTORY>

The download command targets pipeline artifacts. For other artifact types, or the full log archive, use the build UI's download action. Inspect the actual output against the selected pipeline's baseline; do not assume every pipeline publishes PackageArtifacts or BlobArtifacts.

Common Tasks

Monitoring a long-running build

There is no az pipelines watch command. For a long build, use one detached watcher per build ID that polls az pipelines build show, writes result.json and watch.log under the session artifacts directory, and optionally notifies on completion. Check for an existing watcher first; do not leave a duplicate foreground polling loop running. Surface authentication/network failures instead of treating them as completion.