feat: improve pipeline log extraction for catchError and parallel failures

[lidiams96]

Problem

The current PipelineLogExtractor has two limitations that cause it to miss real errors in production pipelines:

1. Single-match Strategy 1: The FlowGraph walk returns on the first ErrorAction+LogAction node found. In pipelines with parallel failures (e.g. multiple test runner pods crashing simultaneously), only the first error is captured and subsequent failures are dropped.

2. catchError + sh(returnStatus:true) + error() pattern not detected: This common pipeline pattern is invisible to Strategy 1. sh(returnStatus:true) does not throw so it has no ErrorAction. The subsequent error() step records an ErrorAction but has no LogAction (it only carries the message string, not the sh output). Strategy 1 finds the error() node, skips it (no LogAction), and falls back to run.getLog(maxLines) — which returns the last N lines of the full console log and misses the actual error output when the build has many subsequent steps.

Solution

Strategy 1 — multi-collect: Instead of returning on the first ErrorAction+LogAction match, accumulate logs from all matching nodes up to maxLines, using a HashSet to deduplicate by origin node ID (reverse-chronological walk may visit the same origin via multiple FlowGraph paths).

Strategy 2 (new) — WarningAction walk: Runs only when Strategy 1 finds nothing. Walks the FlowGraph looking for step nodes with a LogAction enclosed by a BlockStartNode carrying a WarningAction worse than SUCCESS. This handles pipeline variants where catchError records a WarningAction on the block's start node rather than an ErrorAction on the failing step. Requires ≥ 2 lines matching the error pattern to avoid capturing CI infrastructure steps (e.g. a curl command whose JSON payload happens to contain "failed") ahead of the actual failing step log.

Strategy 3 — always-on supplement: The error pattern scan previously ran only as a final fallback when all other strategies produced nothing. It now always runs after Strategies 1 and 2, filling the remaining maxLines budget with lines from the full console log that match error keywords (error, exception, failed, fatal) plus ±5 lines of surrounding context. Lines already captured by Strategies 1 or 2 are skipped via HashSet deduplication. This reliably surfaces the catchError+sh(returnStatus:true)+error() pattern and catches errors buried early in large build logs.

Alternatives

• Keeping Strategy 3 as fallback only: The existing approach worked for simple pipelines but missed the catchError+error() case where Strategy 1 finds an ErrorAction node with no usable log. The supplement approach avoids redundant I/O when Strategies 1/2 already filled the budget and adds no overhead when Strategy 3 has nothing new to contribute.

Additional Context

Validated against a real production Jenkins pipeline (complex parallel build with thousands of tests across multiple parallel groups, ~30,000 line build log):

• Before: the plugin fell back to the last N lines and surfaced unrelated warnings instead of the actual failing step
• After: the plugin correctly surfaces the error from inside the catchError block

The 5 new integration tests in PipelineLogExtractorTest cover all three strategies and include an end-to-end test that verifies the AI provider receives the inner catchError content rather than the generic fallback log.

[Copilot]

Pull request overview

Improves PipelineLogExtractor so the plugin captures more accurate failure logs in complex pipelines (parallel failures and catchError + sh(returnStatus:true) + error() patterns), reducing reliance on the last-N-lines fallback and better surfacing real error output for AI analysis.

Changes:

• Update pipeline FlowGraph extraction to collect logs from multiple failing nodes and add a WarningAction-based walk.
• Add an always-on console-log error-pattern supplement to fill remaining maxLines.
• Add new Jenkins integration tests covering key extraction scenarios and an end-to-end verification via TestProvider.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
src/main/java/io/jenkins/plugins/explain_error/PipelineLogExtractor.java	Implements multi-strategy log extraction (multi-collect, WarningAction walk, pattern-scan supplement) and deduping.
src/test/java/io/jenkins/plugins/explain_error/PipelineLogExtractorTest.java	Adds integration + end-to-end tests validating improved extraction behavior in realistic Pipeline scenarios.

[Copilot]

These integration tests rely on the Pipeline sh step, which fails on Windows ("sh is only supported on Unix"). If CI or downstream builds run tests on Windows, consider guarding with an assumption/skip when not Unix, or using a cross-platform approach (e.g., bat when on Windows) so the suite remains portable.

[lidiams96]

Fixed in commit 7cc4b8d. All five tests that use the Pipeline sh step are now annotated with @DisabledOnOs(OS.WINDOWS), which skips them on Windows CI while allowing them to run on all other Unix-like platforms (Linux, Mac, etc.).

Note: OS.UNIX was removed in JUnit Jupiter 6.x (only LINUX, MAC, WINDOWS, etc. remain), so @DisabledOnOs(OS.WINDOWS) is the correct portable alternative — it covers all non-Windows platforms without listing them explicitly.

[Copilot]

Strategy 2 (WarningAction walk) is described here and implemented in PipelineLogExtractor, but this test suite doesn’t include a scenario that forces Strategy 1 to return empty and then asserts Strategy 2 behavior. Consider adding a dedicated integration test for the WarningAction-only variant so Strategy 2 is regression-protected.

[lidiams96]

Added in commit 808a249: strategy2_catchErrorWithWarningAction_extractsStepLog tests the scenario where catchError(buildResult:'FAILURE', stageResult:'FAILURE') wraps a direct sh failure, causing the BlockStartNode to receive a WarningAction worse than SUCCESS.

One note worth documenting here: Strategy 2 cannot be fully isolated from Strategy 1 in a black-box integration test. When sh 'exit 1' fails inside catchError, Jenkins CPS may or may not attach ErrorAction+LogAction to the sh FlowNode depending on the version and variant — if it does, Strategy 1 finds the content first (Strategy 2 never runs). The test therefore asserts that the content is extracted by Strategy 1 or Strategy 2, protecting against regressions in the WarningAction walk code path without making assumptions about which strategy fires in a given Jenkins version.