Fix CI analysis misclassifying setup failures - #20126
Ella Hathaway (ellahathaway) wants to merge 1 commit into
Conversation
Preserve job-log diagnostics, show skipped steps, and require matching failure evidence before reusing a prior cause. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 20126Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 20126" |
Tests selector1 / 99 PR test projects · 0 PR jobs, from 4 changed files. Selected PR test projects (1 / 99)
Selected PR jobs (0)none How these were chosen — grouped by what changed📄 📄 📄 🧪 Job reasonsnone Selection computed for commit |
There was a problem hiding this comment.
🟢 Approval recommended
The implementation is focused, generated workflow stays synchronized, and regression coverage addresses the reported failure mode.
Pull request overview
Updates CI failure analysis to distinguish prerequisite/setup failures from recurring flaky tests.
Changes:
- Preserves sanitized job-log diagnostics and strips terminal escapes.
- Reports skipped steps and tightens prior-cause matching.
- Adds focused workflow and formatter regression tests.
File summaries
| File | Description |
|---|---|
.github/workflows/analyze-ci-failure.md |
Updates collection and classification logic. |
.github/workflows/analyze-ci-failure.lock.yml |
Regenerates the compiled workflow. |
.github/workflows/analyze-ci-failure.js |
Adds safe job-log normalization. |
tests/Infrastructure.Tests/WorkflowScripts/AnalyzeCiFailureWorkflowTests.cs |
Covers diagnostics and workflow wiring. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 0
- Review effort level: Balanced (auto)
Note
Copilot is running an experiment and ran this review at Balanced.
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
Merge #19455 onto current main while preserving its trusted shell-based validation and persistence flow. Keep current TRX stdout/stderr diagnostics, and incorporate #20126's setup-failure safeguards so failed downloads cannot be mistaken for recurring test failures. Preserve job-log fetch diagnostics and require classifications to match the current failed phase and evidence. Regenerate and validate the gh-aw lock file. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
[automated] The current diffs for this PR and #19455 now cover the same setup-failure scenario:
#19455 also addresses the broader attribution, evidence-validation, persistence, and publication paths around this logic. I suggest landing #19455 first. If it lands in its current form, the remaining behavior in this PR appears to be superseded. |
Closing in favor of #19455 |
Description
CI analysis reopened #19639 after an Azure Functions Core Tools download failed with HTTP 504 / curl exit code 22, even though
Run extension E2E testswas skipped. The analyzer reused the older flaky-test cause based on the shard name rather than the current failure.This keeps the fix limited to that misclassification:
The existing classifications, publishing flow, issue handling, and extension E2E tests are unchanged.
Validation
AnalyzeCiFailureWorkflowTests: 42 passed, including two small regression theories for log diagnostics and collector wiring.Fixes #19639
Checklist
<remarks />and<code />elements on your triple slash comments?