// Investigate CI failures for dotnet/maui PRs — build errors, Helix test logs, and binlog analysis. Use when asked about failing checks, CI status, test failures, 'why is CI red', 'build failed', 'what's failing on PR', Helix failures, or device test failures.
Labels issues and pull requests in the dotnet/maui repository with `area-*` and `platform/*` labels ONLY, based on technical content and platform-file conventions. Used by the gh-aw agentic-labeler workflow and available for batch evaluation and interactive Copilot CLI usage.
MAUI-specific dependency flow rules, channel conventions, and feed lookup workflows. Use when asked about darc, BAR, Maestro, feeds for .NET MAUI, build promotion, asset lookup, channel mappings, or dependency flow for dotnet/maui. Wraps the maestro-cli skill and maestro MCP tools with MAUI-specific guardrails.
End-to-end PR reviewer for dotnet/maui. Orchestrates 3 phases — Pre-Flight, Try-Fix, Report. Gate runs separately before this skill. Use when asked to 'review PR #XXXXX', 'work on PR #XXXXX', or 'fix issue #XXXXX'.
Deep code review of PR changes for correctness, safety, and MAUI conventions. Uses independence-first assessment (code before narrative) and delegates to the maui-expert-reviewer agent for per-dimension sub-agent evaluation. Triggers on: "review code for PR", "code review PR", "analyze code changes", "check PR code quality". Do NOT use for: summarizing PRs, describing what changed, general PR questions, running tests, or fixing code.
Attempts ONE alternative fix for a bug, tests it empirically, and reports results. ALWAYS explores a DIFFERENT approach from existing PR fixes. Use when CI or an agent needs to try independent fix alternatives. Invoke with problem description, test command, target files, and optional hints.
Verifies tests catch the bug. Auto-detects test type (UI tests, device tests, unit tests) and dispatches to the appropriate runner. Supports two modes - verify failure only (test creation) or full verification (test + fix validation).
| name | azdo-build-investigator |
| description | Investigate CI failures for dotnet/maui PRs — build errors, Helix test logs, and binlog analysis. Use when asked about failing checks, CI status, test failures, 'why is CI red', 'build failed', 'what's failing on PR', Helix failures, or device test failures. |
| metadata | {"author":"dotnet-maui","version":"2.0"} |
This skill provides MAUI-specific context for CI investigation. Use it together with the ci-analysis skill (loaded from the dotnet-dnceng@dotnet-arcade-skills plugin via .github/copilot/settings.json).
First: invoke the
ci-analysisskill — it handles the core investigation workflow usingGet-CIStatus.ps1andghCLI (with MCP tools as optional enhancements if available). This skill provides MAUI-specific corrections and context on top of that.
The ci-analysis skill and its Get-CIStatus.ps1 script are loaded automatically from the dotnet/arcade-skills plugin (configured in .github/copilot/settings.json via enabledPlugins). The CLI caches scripts to ~/.copilot/installed-plugins/dotnet-arcade-skills/. No manual download is needed.
⚠️ The
ci-analysisskill's reference doc listsmaui-publicas the MAUI pipeline — this is outdated. The correct pipeline names are below.
| Pipeline Name | Definition ID | Purpose |
|---|---|---|
maui-pr | 302 | Main build — check this first |
maui-pr-devicetests | 314 | Helix device tests (iOS, Android, Windows, MacCatalyst) |
maui-pr-uitests | 313 | Appium-based UI tests |
Organization: dnceng-public / project public
Investigation priority order: maui-pr → maui-pr-devicetests → maui-pr-uitests
Most failures are in maui-pr. Device test failures appear in maui-pr-devicetests. Focus on the first failing pipeline before checking others.
When CI hasn't run: Community PRs require a maintainer to trigger builds. Use /azp run maui-pr (or maui-pr-devicetests, maui-pr-uitests) in a PR comment, or trigger via Azure CLI. Not all pipelines run automatically — maui-pr-devicetests and maui-pr-uitests may need explicit triggers depending on the changed files.
Escalation: For deep Helix log analysis (recurring failures, machine-specific issues, comparing passing vs. failing runs), escalate to the helix-investigation skill.
XHarness (used for iOS/Android device tests in maui-pr-devicetests) exits with code 0 even when tests fail. This means:
ci-analysis may report no failuresHow to detect hidden test failures: Query the ResultSummaryByBuild Helix API endpoint:
GET https://helix.dot.net/api/2019-06-17/jobs/{correlationId}/aggregated
Look for Failed > 0 in the response even when the ADO build job shows green.
When ci-analysis reports a maui-pr-devicetests build as passing but the PR has a s/agent-gate-failed label or the user suspects device test failures, always cross-check Helix ResultSummaryByBuild.
MAUI build artifacts are Container type, not PipelineArtifact. This means:
az pipelines runs artifact download does not work for binlogsWindows_NT_Build Windows (Debug)_Attempt1 (not binlog)az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798/_apis/resources/Containers/{id}?api-version=5.0-preview&$format=OctetStreamIf available, use the mcp-binlog-tool MCP server to analyze downloaded .binlog files. This is optional — the core investigation workflow works without it via gh CLI and REST APIs.
| Pattern | Where | Notes |
|---|---|---|
error CS#### | maui-pr | C# compiler error — check file/line |
error XA#### | maui-pr | Android build error |
XamlC | maui-pr | XAML compiler — usually missing type or bad binding |
error XAGRDL0000 / 401 / No local versions | maui-pr or official build | Gradle/Maven feed issue — see below |
XHarness timeout | maui-pr-devicetests Helix logs | Test killed by infrastructure; may be transient |
No test result files found | maui-pr-devicetests Helix logs | Tests never ran or app crashed on launch |
| UI test screenshot diff | maui-pr-uitests | Visual regression; check baseline images |
When querying AzDO test results directly (e.g., via the /test/runs/{id}/results API), always deduplicate before reporting counts. MAUI UI tests produce multiple test runs per test because each test executes across:
A single failing test can appear in 4–8+ test runs. Summing raw totalTests - passedTests across all runs inflates failure counts dramatically.
How to deduplicate: Group by test name + OS platform (extract the OS token — ios, android, mac, win — from the run name as the grouping key). For example, "DatePicker_Format_D on iOS" vs "DatePicker_Format_D on Android" are distinct failures worth reporting separately. Collapse retries and runtime variants (coreclr/mono) of the same test on the same OS — if a test fails on both coreclr and mono for iOS, that's one issue, not two.
Error signatures:
error XAGRDL0000: Could not resolve com.android.tools.build:gradle:8.11.1
> Received status code 401: Unauthorized - No local versions of package
error XAGRDL0000: Could not GET '...pkgs.dev.azure.com/.../maven/v1/...'
> Unauthorized - Please provide authentication to save package from upstream
Fix: Tell the user to run ./eng/ingest-maven-deps.sh locally to pre-ingest packages into the feed.
Do NOT:
ci-official.yml — security compliance requirementdotnet/android#10738mavenCentral() or google() back — use the Azure Artifacts feed