agentleFS
redhat-developerredhat-developer/rhdh/.claude/skills/e2e-parse-ci-failure/SKILL.md

e2e-parse-ci-failure

Skill171 starsChanged 20 days agoApache-2.0View on GitHub

Parse a Prow CI job URL or Jira ticket to extract E2E test failure details including test name, spec file, release branch, platform, and error messages

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this skill when you receive a failing Prow job URL (e.g., https://prow.ci.openshift.org/view/gs/...), a Jira ticket ID (e.g., …

    line 13
  2. Distinctive:

    Search the build log for these Playwright output patterns:

    line 53
  3. Very specific:

    If Playwright MCP is not available, derive the build-log.txt URL from the report URL and fall back to build log parsing.

    line 76
  4. Distinctive:

    Use Jira MCP tools to read the ticket.

    line 80
  5. Very specific:

    When parsing a job name, apply those mapping tables to derive: release branch, platform, deployment method, Playwright projects, and …

    line 91
  6. Distinctive:

    Not all output fields can be derived from the Prow URL alone.

    line 95

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Parse CI Failure

Extract structured failure context from a Prow job URL or Jira ticket for an RHDH E2E CI failure.

When to Use

Use this skill when you receive a failing Prow job URL (e.g., https://prow.ci.openshift.org/view/gs/...), a Jira ticket ID (e.g., RHIDP-XXXX), or a Jira URL (e.g., https://redhat.atlassian.net/browse/RHIDP-XXXX) for an E2E test failure and need to extract all relevant details before starting a fix.

Input Detection

  • Playwright report URL: URL ending in index.html (with optional #?testId=... fragment) — use Playwright MCP if available (see "Playwright Report Parsing" below), otherwise fall back to build log parsing
  • Prow URL: Starts with https://prow.ci.openshift.org/ — parse the job page and build log
  • Jira ticket ID: Matches pattern RHIDP-\d+ or similar — use Jira MCP tools to read the ticket
  • Jira URL: Starts with https://redhat.atlassian.net/browse/ — extract the ticket ID from the URL path (e.g., RHIDP-XXXX from https://redhat.atlassian.net/browse/RHIDP-XXXX) and then use Jira MCP tools to read the ticket

Prow URL Parsing

URL Structure

Prow job URLs follow two patterns:

  • Periodic/postsubmit: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/<job-name>/<build-id>
  • Presubmit (PR): https://prow.ci.openshift.org/view/gs/test-platform-results/pr-logs/pull/redhat-developer_rhdh/<pr-number>/<job-name>/<build-id>

Extract <job-name> and <build-id> from the URL path. These are the two key values needed for all derivations.

GCS URL Derivation

Convert the Prow URL to a GCS artifacts URL by replacing the prefix:

Prow:  https://prow.ci.openshift.org/view/gs/test-platform-results/logs/<job-name>/<build-id>
GCS:   https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/logs/<job-name>/<build-id>/artifacts/

For presubmit jobs, use pr-logs/pull/redhat-developer_rhdh/<pr-number>/ instead of logs/.

Key artifacts within the GCS directory:

  • Build log: <step-name>/build-log.txt
  • JUnit XML: <step-name>/artifacts/junit-results/results.xml
  • Playwright report: <step-name>/artifacts/playwright-report/

Fetch the Prow job page with WebFetch to find the job status and artifact links, then fetch the build log for test failure details.

Extracting Test Failures from Build Log

Search the build log for these Playwright output patterns:

# Failing test line (primary source for test name, spec file, and project):
  ✘  [<project>] › <path>/<spec-file>.spec.ts:<line> › <test-describe> › <test-name>

# Error details (immediately after the failure line):
  Error: <error-message>
  expect(received).toBeVisible()
  Locator: <locator>

# Summary (at the end of the log):
  X failed
  X passed
  X skipped

Also check JUnit XML for <testcase> elements with <failure> children as a fallback.

Playwright Report Parsing

When the URL points to a Playwright HTML report (index.html, optionally with #?testId=...), use Playwright MCP if available — navigate with browser_navigate, then browser_snapshot to extract test name, spec file, error, steps, retries, screenshots, and traces from the accessibility tree. Derive job metadata (<job-name>, <build-id>, <project>) from the URL path segments.

If Playwright MCP is not available, derive the build-log.txt URL from the report URL and fall back to build log parsing.

Jira Ticket Parsing

Use Jira MCP tools to read the ticket. Extract:

  1. Prow job URLs from the description or comments — then parse them using the Prow URL Parsing steps above.
  2. Test names, spec file paths, error messages, or stack traces from the description, comments, or attachments.
  3. affects version field — map to release branch (e.g., 1.10 → main, 1.9 → release-1.9, 1.8 → release-1.8).
  4. component field for additional context (e.g., "E2E Tests", "CI/CD").

Job Name Mapping

Refer to the e2e-fix-workflow rule for all mapping tables: job name to release branch, job name to platform and deployment method, job name to Playwright projects, release branch to image repo/tag, and job name to local-run.sh -j parameter. Those tables are the single source of truth and should not be duplicated here.

When parsing a job name, apply those mapping tables to derive: release branch, platform, deployment method, Playwright projects, and local-run.sh flags (-j, -r, -t).

Fields Requiring Build Log Access

Not all output fields can be derived from the Prow URL alone. The following table clarifies what requires fetching the build log or artifacts:

FieldSourceDerivable from URL alone?
Job nameURL path segmentYes
Build IDURL path segmentYes
Release branchJob name pattern matchYes
PlatformJob name pattern matchYes
Deployment methodJob name pattern matchYes
Playwright projectsJob name pattern matchYes
local-run.sh flags (-j, -r, -t)Job name + release branchYes
GCS artifacts URLConstructed from URLYes
Test nameBuild log Playwright outputNo — requires build log
Spec fileBuild log Playwright outputNo — requires build log
Specific Playwright project (of failing test)Build log [project] prefixNo — requires build log
Error typeBuild log error detailsNo — requires build log
Error messageBuild log error detailsNo — requires build log
Failure count / pass countBuild log summary lineNo — requires build log

Output

Produce the following structured output with three sections.

1. Structured Summary

- Test name: <full test name from Playwright output>
- Spec file: <path relative to e2e-tests/playwright/>
- Playwright project: <specific project from the [project] prefix in the failure line>
- Release branch: <main or release-X.Y>
- Platform: <OCP/AKS/EKS/GKE/OSD-GCP>
- Deployment method: <Helm/Operator>
- Error type: <locator/timeout/assertion/crash/deployment>
- Error message: <the actual error>
- Prow URL: <original URL>
- Jira ticket: <ticket ID if applicable>

2. Derivation Details

Show how each field was derived with the matching pattern. This makes the reasoning transparent and auditable.

| Field              | Value                        | Derivation                                                |
|--------------------|------------------------------|-----------------------------------------------------------|
| Job name           | <full-job-name>              | Extracted from URL path segment                           |
| Build ID           | <build-id>                   | Extracted from URL path segment                           |
| Release branch     | <branch>                     | Pattern `*-rhdh-<branch>-*` matched in job name           |
| Platform           | <platform>                   | Pattern `*<platform-keyword>*` matched in job name        |
| Deployment method  | <method>                     | Pattern `*<method-keyword>*` matched in job name          |
| Playwright project | <project>                    | `[<project>]` prefix in failing test line                 |
| Image repo (-r)    | <repo>                       | Release branch `<branch>` maps to `<repo>`                |
| Image tag (-t)     | <tag>                        | Release branch `<branch>` maps to `<tag>`                 |
| Test name          | <test-name>                  | Parsed from `✘` line in build log                         |
| Spec file          | <spec-file>                  | Parsed from `✘` line in build log                         |
| Error type         | <error-type>                 | Classified from error message pattern                     |

3. GCS Artifacts Location

Derive and present the GCS artifacts URLs constructed from the Prow URL:

GCS Artifacts Base:
  https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/logs/<job-name>/<build-id>/artifacts/

Build Log:
  <base>/artifacts/<step-name>/build-log.txt

JUnit Results:
  <base>/artifacts/<step-name>/artifacts/junit-results/results.xml

Playwright Report:
  <base>/artifacts/<step-name>/artifacts/playwright-report/

For presubmit (PR) jobs, the base path uses pr-logs/pull/redhat-developer_rhdh/<pr-number>/ instead of logs/.

4. local-run.sh Command

Provide the full command ready to copy-paste, with a flag breakdown.

OCP jobs — use -s for deploy-only mode:

cd e2e-tests
./local-run.sh -j <full-job-name> -r <image-repo> -t <image-tag> -s

Flag breakdown:
| Flag | Value              | Reason                                           |
|------|--------------------|--------------------------------------------------|
| -j   | <full-job-name>    | Full Prow job name (matches glob in CI script)   |
| -r   | <image-repo>       | Image repo derived from release branch <branch>  |
| -t   | <image-tag>        | Image tag derived from release branch <branch>   |
| -s   | (no value)         | Deploy only, skip running tests                  |

K8s jobs (AKS, EKS, GKE) — do not use -s; full execution is required:

cd e2e-tests
./local-run.sh -j <full-job-name> -r <image-repo> -t <image-tag>

Flag breakdown:
| Flag | Value              | Reason                                           |
|------|--------------------|--------------------------------------------------|
| -j   | <full-job-name>    | Full Prow job name (matches glob in CI script)   |
| -r   | <image-repo>       | Image repo derived from release branch <branch>  |
| -t   | <image-tag>        | Image tag derived from release branch <branch>   |

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.