azdo-build-investigator

Investigates dotnet/maui CI failures across Azure DevOps pipelines, Helix tests, and binlogs.

23.3k|2.0k|Updated May 8, 2020
One-click install
npx skills add https://github.com/dotnet/maui --skill azdo-build-investigator
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: azdo-build-investigator
Source: https://github.com/dotnet/maui/tree/main/.github/skills/azdo-build-investigator
Command: npx skills add https://github.com/dotnet/maui --skill azdo-build-investigator

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Diagnosing why a dotnet/maui pull request or nightly build is failing requires navigating multiple Azure DevOps pipelines, Helix device-test logs, and MSBuild binlogs, which is slow and error-prone without MAUI-specific knowledge.

Core Features & Use Cases

  • PR CI Investigation: Gathers build and test status for the maui-pr, maui-pr-devicetests, and maui-pr-uitests pipelines, applying MAUI-specific corrections such as the XHarness exit-0 blind spot and test-count deduplication.
  • Merge-Readiness Assessment: Compares failures against the base branch and classifies a PR as ready to merge, not ready, or needing human investigation.
  • Nightly Build Triage: Investigates the official signed build (definition 1095 on dnceng/internal) when the inflight dogfood feed goes stale, including known Pack Windows failure signatures.
  • Use Case: A maintainer asks why CI is red on a community PR; the skill pulls the failing timeline, checks Helix aggregated results for hidden device-test failures, and reports whether the failures pre-exist on the base branch.

Quick Start

Ask why CI is failing on a specific dotnet/maui pull request or whether the nightly build is broken.

Frequently Asked Questions about azdo-build-investigator

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I investigate why CI is failing on a dotnet/maui pull request?

Query the maui-pr (302), maui-pr-devicetests (314), and maui-pr-uitests (313) pipelines via the Azure DevOps public REST APIs, then inspect the failed timeline step and its log. Cross-check device tests with the Helix aggregated endpoint to catch failures hidden by the XHarness exit-0 blind spot.

How do I check if a dotnet/maui PR is ready to merge?

Compare the PR's failures against the base branch to determine whether they are pre-existing. Apply the merge-readiness criteria to classify the result as ready to merge, not ready, needs human investigation, or insufficient data.

Why does the maui-pr-devicetests pipeline show green when device tests failed?

XHarness can exit with code 0 even when device tests fail, so the Azure DevOps job appears successful. Query the Helix aggregated endpoint for the work items to reveal the hidden failures.

How do I investigate the dotnet/maui nightly build or stale dogfood feed?

Investigate the dotnet-maui pipeline, definition ID 1095, in the dnceng/internal project on the inflight/current branch. Find the newest failed run, search its timeline for the failing step, and read the step log; the Pack Windows job is the most common failure point.

What causes the MSB4019 vs-workload.props error in the official build?

The error occurs when vs-workload.props is missing at import time because the manifest pack step did not stage it. A known cause was a blanket IsPackable=false rule for netstandard targets that disabled packing and prevented the _GenerateVSWorkloadProps target from running.