Onboard build failure analysis workflow

.github/aw/actions-lock.json

@@ -50,5 +50,17 @@
       "version": "v0.86.2",
       "sha": "6aab9e5b5c91c615506061f09bedd81a23babe3c"
     }
+  },
+  "containers": {
+    "ghcr.io/lewing/helix.mcp:v0.8.0": {
+      "image": "ghcr.io/lewing/helix.mcp:v0.8.0",
+      "digest": "sha256:3c0a16544d922f17ebb477df4d4b0bd546815eb6b1200f4fd8291809011fc20f",
+      "pinned_image": "ghcr.io/lewing/helix.mcp:v0.8.0@sha256:3c0a16544d922f17ebb477df4d4b0bd546815eb6b1200f4fd8291809011fc20f"
+    },
+    "mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-binlog-mcp-amd64": {
+      "image": "mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-binlog-mcp-amd64",
+      "digest": "sha256:253736e28e0230269dfcdb70f5027da47e2e45e8526d15d6485ca08b2c2f1638",
+      "pinned_image": "mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-binlog-mcp-amd64@sha256:253736e28e0230269dfcdb70f5027da47e2e45e8526d15d6485ca08b2c2f1638"
+    }
   }
 }

.github/workflows/shared/build-failure-analysis-shared.md

@@ -0,0 +1,87 @@
+---
+# Shared body for the build-failure-analysis workflows.
+#
+# Imported by build-failure-analysis.md (check_run + workflow_dispatch
+# triggers) and build-failure-analysis-command.md (slash command). Keeps the
+# prompt that drives the build-failure analysis in one place. Per-trigger
+# wiring (steps, env, mcp-servers, permissions) lives in each caller because
+# gh-aw merges those fields from imports but each main workflow must still
+# re-declare its top-level permissions.
+
+description: "Shared body for build-failure-analysis workflows"
+---
+
+# Build Failure Analyst
+
+You are the **build-failure analyst**. Analyze the binary logs of the Azure
+DevOps build that just failed, plus its failed compile-task logs where Runtime
+did not publish a matching binlog, and produce a PR review using the
+safe-output tools (a later `safe_outputs` job performs the actual GitHub write).
+Do **not** try to spawn a sub-agent: the `task` tool is intentionally not
+available here. Work directly with the tools you do have: `binlog-mcp` to
+read the logs, the `github` tools to read PR/repo context (the GitHub MCP
+server is **read-only** here), the `safeoutputs` tools (`add_comment`,
+`create_pull_request_review_comment`, `noop`) to post results, and a small set
+of read-only `shell` commands (including `cat`).
+
+## Instructions
+
+1. Read the agent-context environment variables: `GH_AW_BUILD_OUTCOME`,
+   `GH_AW_BINLOG_LIST`, `GH_AW_BINLOG_DIR`, `GH_AW_BINLOG_PATH`,
+   `GH_AW_BINLOG_HOST_PATH`, `GH_AW_PR_NUMBER`, `GH_AW_PR_HEAD_SHA`,
+   `GH_AW_PR_MERGE_SHA`, `GH_AW_WORKSPACE`.
+
+2. If `GH_AW_BUILD_OUTCOME == 'success'`, the build did not actually fail —
+   there is nothing to analyze. Call `noop` with the message
+   `"Build succeeded — no analysis required."` and stop.
+
+3. Load your detailed playbook: `cat .github/agents/build-failure-analyst.agent.md`
+   (it is checked out with the repository config). Follow that methodology —
+   root-cause grouping, source-context reading via the GitHub API at
+   `GH_AW_PR_HEAD_SHA`, comment/suggestion formatting, and defensive behavior.
+   In summary:
+   - Start with `azdo_timeline` from the `hlx` MCP server for
+     `GH_AW_BINLOG_HOST_PATH` using
+     `filter: "failed"` to inventory **every** failed/canceled job and task.
+     Treat only compile/build/configure/link tasks as build evidence; Helix,
+     test execution, publishing, and infrastructure failures remain out of
+     scope. For each failed compile task that is not explained by a retrieved
+     binlog or by complete build diagnostics in its timeline `issues`, use
+     `azdo_search_log` from `hlx` against that task's `logId` with bounded
+     searches for compiler/MSBuild/native-build failure signatures. This is
+     required even when some binlogs were retrieved: Runtime job display names
+     and artifact names are not one-to-one, and some compile jobs publish no
+     `Logs_Build_*` artifact.
+   - Iterate **every** path in `GH_AW_BINLOG_LIST` when the list is non-empty
+     (newline-separated in-container binlog paths from failed/canceled build
+     jobs, under `GH_AW_BINLOG_DIR` = `/data/binlogs`) and query the
+     `binlog-mcp` MCP server (`binlog_errors`, `binlog_overview`,
+     `binlog_warnings`, …) with `binlog_file` set to each leg's path — a
+     failure usually surfaces in only one leg, so do not analyse just the
+     first. `binlog_errors`,
+     `binlog_overview`, `binlog_warnings`, … are **MCP tools** provided by the
+     `binlog-mcp` server: prefer calling them **directly as MCP tools** (with a
+     `binlog_file` argument). A CLI wrapper is also mounted and allowlisted, so
+     you may alternatively run `binlog-mcp <tool> --binlog_file <path>` via the
+     shell.
+   - If no binlog shows errors or failed-target/process evidence **and** the
+     bounded hlx task-log checks show no compile/build failure, the build work
+     compiled cleanly — the pipeline failure is then a **non-build**
+     (test/Helix/publishing/infrastructure) failure, which is **out of scope**.
+     Only make that clean-build conclusion when all required binlog and hlx
+     queries succeeded. Then **post nothing**: call `noop` with a short reason
+     and stop. Do **not** post a summary comment and do **not** invent fixes.
+     If a required query fails and the gap prevents classification, post one
+     incomplete-analysis summary with the Azure DevOps build link and no fix
+     claim or inline suggestion.
+   - Post exactly one summary via `add_comment` with structured data
+     `{"workflow_artifact":"build-failure-analysis","artifact_kind":"analysis"}`
+     and any inline
+     `suggestion` blocks via `create_pull_request_review_comment`. Both
+     workflows bind safe outputs deterministically to `GH_AW_PR_NUMBER`; do
+     not attempt to choose or override the target in a safe-output call.
+   - `submit_pull_request_review` is **not** a safe output for this workflow;
+     inline comments stand alone.
+
+4. When you have posted the analysis for a genuine build failure (or called
+   `noop` for a clean-compile / non-build failure), stop.