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
- Very specific: line 13
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., …
- Distinctive: line 53
Search the build log for these Playwright output patterns:
- Very specific: line 76
If Playwright MCP is not available, derive the build-log.txt URL from the report URL and fall back to build log parsing.
- Distinctive: line 80
Use Jira MCP tools to read the ticket.
- Very specific: line 91
When parsing a job name, apply those mapping tables to derive: release branch, platform, deployment method, Playwright projects, and …
- Distinctive: line 95
Not all output fields can be derived from the Prow URL alone.
≈ “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.
Files
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-XXXXfromhttps://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 skippedAlso 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:
- Prow job URLs from the description or comments — then parse them using the Prow URL Parsing steps above.
- Test names, spec file paths, error messages, or stack traces from the description, comments, or attachments.
affects versionfield — map to release branch (e.g.,1.10→main,1.9→release-1.9,1.8→release-1.8).componentfield 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:
| Field | Source | Derivable from URL alone? |
| Job name | URL path segment | Yes |
| Build ID | URL path segment | Yes |
| Release branch | Job name pattern match | Yes |
| Platform | Job name pattern match | Yes |
| Deployment method | Job name pattern match | Yes |
| Playwright projects | Job name pattern match | Yes |
local-run.sh flags (-j, -r, -t) | Job name + release branch | Yes |
| GCS artifacts URL | Constructed from URL | Yes |
| Test name | Build log Playwright output | No — requires build log |
| Spec file | Build log Playwright output | No — requires build log |
| Specific Playwright project (of failing test) | Build log [project] prefix | No — requires build log |
| Error type | Build log error details | No — requires build log |
| Error message | Build log error details | No — requires build log |
| Failure count / pass count | Build log summary line | No — 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> |In this repository20 other files it gives its agents.
- .cursor/rules/add_extension_metadata.mdcCursor rule
- .cursor/rules/ci-e2e-testing.mdcCursor rule
- .cursor/rules/e2e-coverage-imports.mdcCursor rule
- .cursor/rules/e2e-fix-workflow.mdcCursor rule
- .cursor/rules/github-workflows-security.mdcCursor rule
- .cursor/rules/managing-ai-rules.mdcCursor rule
- .cursor/rules/playwright-locators.mdcCursor rule
- e2e-deploy-rhdhSkill
- e2e-diagnose-and-fixSkill
- e2e-reproduce-failureSkill
- e2e-submit-and-reviewSkill
- e2e-verify-fixSkill
- patch-backstageSkill
- e2e-deploy-rhdhSkill
- e2e-diagnose-and-fixSkill
- e2e-parse-ci-failureSkill
- e2e-reproduce-failureSkill
- e2e-submit-and-reviewSkill
- e2e-verify-fixSkill
- patch-backstageSkill
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
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.

