Skip to content

docs(e2e): add E2E layer migration matrix (RHIDP-15076)#5044

Open
gustavolira wants to merge 2 commits into
redhat-developer:mainfrom
gustavolira:rhidp-15076-layer-migration-matrix
Open

docs(e2e): add E2E layer migration matrix (RHIDP-15076)#5044
gustavolira wants to merge 2 commits into
redhat-developer:mainfrom
gustavolira:rhidp-15076-layer-migration-matrix

Conversation

@gustavolira

@gustavolira gustavolira commented Jul 2, 2026

Copy link
Copy Markdown
Member

Summary

Publishes the Phase-1 deliverable of RHIDP-15076 ([Test Strategy] E2E Test Optimization epic RHIDP-13501): the E2E → lower-layer migration matrix.

The Jira story's closing comment references this document by path (rhdh/docs/e2e-tests/layer-migration-matrix.md), but it had never been committed — this PR closes that gap.

Contents

  • Classification of all 30 e2e specs by target layer (L1 unit → L4b full-cluster E2E), with per-spec cluster/external-service dependencies.
  • Tally + suggested migration batches (feeding RHIDP-13528 / RHIDP-13529).
  • The 11 specs that must stay cluster-bound (L4b) and why.
  • Companion analysis of the rhdh-plugin-export-overlays test system (smoke vs e2e tiers, native harness recommendation — see overlays#2714).
  • Updated 2026-07-02 with the L4a cluster-free harness validation results from feat(e2e): cluster-free local E2E harness (legacy app, Tier B) #5005: 4 tests green (~3.5 min job), the global-header mount solution, and the recommended order for the next L4a enablements.

This is an additive analysis, not a removal plan — no E2E spec has to be deleted (per the epic).

Related

🤖 Generated with Claude Code

Phase-1 deliverable of RHIDP-15076 (E2E Test Optimization epic
RHIDP-13501): classifies all 30 e2e specs by target layer (L1-L4b),
maps which are supplementable by Layer 3 component tests or the
cluster-free L4a harness, and includes the companion analysis of the
rhdh-plugin-export-overlays test system. Referenced from the Jira
story's closing comment; updated 2026-07-02 with the L4a harness
validation results from PR redhat-developer#5005 (4 tests green cluster-free).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@openshift-ci openshift-ci Bot requested review from albarbaro and thepetk July 2, 2026 19:26
@rhdh-qodo-merge

rhdh-qodo-merge Bot commented Jul 2, 2026

Copy link
Copy Markdown

PR Summary by Qodo

Add E2E→lower-layer migration matrix for test optimization (RHIDP-15076)

📝 Documentation 🕐 20-40 Minutes

Grey Divider

AI Description

• Publish Phase-1 E2E migration matrix covering all 30 Playwright specs and target layers.
• Document L4a cluster-free harness validation results and recommended next enablements.
• Add companion analysis for overlay repo smoke/e2e tiers and cluster-free harness options.
Diagram

graph TD
  A["Playwright E2E specs (30)"] --> B["Layer migration matrix"] --> C["L2 integration targets"]
  B --> D["L3 component targets"]
  B --> E["L4a cluster-free harness"]
  B --> F["L4b stays cluster"]
  B --> G["Overlay repo analysis"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Auto-generate the matrix from test metadata
  • ➕ Stays current as specs change (less manual drift)
  • ➕ Can enforce required fields (cluster/external deps/target layer) via CI checks
  • ➕ Enables querying/slicing (e.g., counts by dependency) without manual edits
  • ➖ Requires introducing/maintaining metadata conventions across specs
  • ➖ Up-front engineering effort may not be justified for a Phase-1 deliverable
  • ➖ May reduce narrative/context that a written doc provides (e.g., rationale)
2. Store the matrix as structured data (YAML/JSON) + rendered Markdown
  • ➕ Keeps human-readable docs while enabling automation (tallying, validation)
  • ➕ Easier to update individual rows without reformatting tables
  • ➕ Can be reused by tooling (dashboards, CI reports)
  • ➖ Adds an extra format and a render step
  • ➖ Requires deciding ownership and update workflow
3. Keep analysis solely in Jira/Confluence
  • ➕ Closer to planning artifacts; easier cross-linking to epics/stories
  • ➕ May fit existing team process for strategy documents
  • ➖ Harder to review/version with code
  • ➖ Less discoverable to engineers working in-repo
  • ➖ Breaks the referenced-by-path expectation noted in the story closure

Recommendation: The PR’s approach (commit the referenced markdown deliverable in-repo) is the right Phase-1 move: it’s reviewable, versioned, and directly addressable by path. If this matrix is expected to evolve frequently as specs change, consider a follow-up that adds minimal per-spec metadata and/or a structured source (YAML/JSON) to prevent drift, while still rendering a human-friendly markdown report.

Files changed (1) +269 / -0

Documentation (1) +269 / -0
layer-migration-matrix.mdAdd Phase-1 E2E layer migration matrix and harness findings +269/-0

Add Phase-1 E2E layer migration matrix and harness findings

• Introduces a new document classifying 30 Playwright E2E specs by target test layer (L2/L3/L4a/L4b) with cluster/external dependency notes, tally, and suggested migration batches. Captures 2026-07-02 L4a cluster-free harness validation results and identifies the cluster-bound (stay L4b) set, plus companion analysis and recommendations for the rhdh-plugin-export-overlays test tiers.

docs/e2e-tests/layer-migration-matrix.md

@codecov

codecov Bot commented Jul 2, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.77%. Comparing base (d8b493f) to head (f7f45ce).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5044      +/-   ##
==========================================
- Coverage   55.39%   54.77%   -0.62%     
==========================================
  Files         122      110      -12     
  Lines        2365     2147     -218     
  Branches      544      513      -31     
==========================================
- Hits         1310     1176     -134     
+ Misses       1049      970      -79     
+ Partials        6        1       -5     
Flag Coverage Δ
rhdh 54.77% <ø> (-0.62%) ⬇️

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d8b493f...f7f45ce. Read the comment docs.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@rhdh-qodo-merge

rhdh-qodo-merge Bot commented Jul 2, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials
✅ Compliance rules (platform): 46 rules

Grey Divider


Remediation recommended

1. Tally count mismatch ✓ Resolved 🐞 Bug ≡ Correctness
Description
The Tally table marks L3 as count=9 while listing 10 specs (#3–#12), making the summary totals
inconsistent with the stated 30-spec matrix and potentially misleading batching/ROI decisions based
on these counts.
Code

docs/e2e-tests/layer-migration-matrix.md[R106-111]

+| Target         | Count | Specs                                       |
+| -------------- | ----- | ------------------------------------------- |
+| **L2**         | 4     | #1, #2, #13, #14                            |
+| **L3**         | 9     | #3\*, #4, #5, #6, #7, #8, #9, #10, #11, #12 |
+| **L4a**        | 5     | #15, #16, #17, #18, #19                     |
+| **L4b (stay)** | 11    | #20–#30                                     |
Relevance

⭐⭐⭐ High

They accept correcting internal doc inconsistencies/mismatched values (docs accuracy fixes merged).

PR-#4255
PR-#4511

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The matrix section is explicitly labeled as 30 specs, but the L3 tally line enumerates ten specs
while the count column says nine, which is a direct internal contradiction.

docs/e2e-tests/layer-migration-matrix.md[65-112]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The L3 row in the **Tally** table has an incorrect `Count` value (shows 9 while enumerating 10 specs). This also makes the tally totals disagree with the “30 specs” claim.

### Issue Context
This document is being used as a planning/source-of-truth matrix; the summary counts should be internally consistent.

### Fix Focus Areas
- docs/e2e-tests/layer-migration-matrix.md[104-113]

### Implementation notes
- Either change the L3 `Count` to `10`, or remove the extra spec from the L3 list (if one of them is not intended to be counted, e.g. `#3 smoke-test`).
- Ensure the four tally counts sum to the stated total in the “Summary matrix” heading.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

2. Spec total wording unclear ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
The document says the dependency scan covered “all 29 specs on main” but then presents a “Summary
matrix (30 specs)” including a pending spec (#19); without a one-line explicit statement (e.g., “29
on main + 1 pending merge”), readers can misinterpret the scope.
Code

docs/e2e-tests/layer-migration-matrix.md[R52-66]

+A fresh dependency scan (2026-07-02) of all 29 specs on `main` confirms the L4b bucket
+below is exactly the CLUSTER-BOUND set (pod-log scraping, ConfigMap patch + restart,
+port-forward, managed DBs, full `RHDHDeployment` lifecycle). Next cheapest L4a
+enablements, in order: #7 `home-page-customization`, #5 `settings` (needs the `team-a`
+ownership entities mirrored), #8 `sidebar`, #10/#11 `application-provider/listener`,
+#9 `user-settings-info-card`, #2 `licensed-users-info` (backend API only), #1
+`instance-health-check`, #3 `smoke-test`. Running a spec on the L4a harness does not
+change its **target layer** — L4a supplements PR-time signal until the L3 equivalents
+land.
+
+Note: #19 `plugin-dynamic-loading` ships with PR #4967, which is still **open** — the
+row below describes its state once merged.
+
+## Summary matrix (30 specs)
+
Relevance

⭐⭐⭐ High

Team previously accepted doc scope/clarity fixes in docs/e2e-tests (explicit statements to avoid
confusion).

PR-#4511

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The document simultaneously states “all 29 specs on main” and labels the matrix as “30 specs”,
while also including a note that #19 is still in an open PR; this supports the scope-clarification
need.

docs/e2e-tests/layer-migration-matrix.md[52-66]
docs/e2e-tests/layer-migration-matrix.md[71-103]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The text references “29 specs on `main`” while also presenting a “30 specs” matrix that includes a spec explicitly noted as pending merge (#19). This is easy to misread.

### Issue Context
The document already notes PR #4967 is open; a small wording tweak can make the scope explicit and avoid confusion.

### Fix Focus Areas
- docs/e2e-tests/layer-migration-matrix.md[52-66]

### Implementation notes
- Update the “Summary matrix (30 specs)” heading to something like “Summary matrix (29 on `main` + 1 pending merge)” OR add a short sentence near the note for #19 stating the matrix includes one additional spec not yet on `main`.
- Optionally ensure other places that cite totals (e.g., ROI / batching text) use the same basis.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

gustavolira added a commit to gustavolira/rhdh that referenced this pull request Jul 2, 2026
…tion, path prefixes

- Mark harnesses that are still in review and instruct the assistant to
  verify paths exist on main before recommending them (the skill referenced
  redhat-developer#5005/redhat-developer#5044/redhat-developer#2714/redhat-developer#4967 deliverables in present tense).
- Describe the overlays native smoke's real interface: yarn smoke
  --dynamic-plugins <file> [--out] (no --workspace flag exists; the harness
  does not read workspaces/*/metadata — a workspace run is a dp.yaml listing
  its oci:// refs).
- Replace the fork-only RHIDP-13235-layer3-component-tests branch pointer
  with the closed PR rhdh#4864.
- Prefix every path with its repo (rhdh:/overlays:/plugins:) and use full
  URLs for cross-repo docs, so the skill resolves from any of its three homes.
- Fix skopeo claim: it installs on macOS via brew; CI has it preinstalled.
- Name the Docker smoke location (overlays smoke-tests/ +
  run-workspace-smoke-tests.yaml), replace the vague "any" repo cell, use
  "n/a (cluster)" for the cluster row's Docker column, move PR numbers to
  References with status, add trigger phrases to the frontmatter description,
  and deduplicate the guiding-rule sentence.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…DME link

- Fix the Tally L3 count (10, not 9) so the column totals sum to the
  30-spec heading; reconcile the heading itself (29 on main + redhat-developer#19 pending
  in PR redhat-developer#4967).
- "runs 4 tests" -> "runs 2 specs (4 test cases)" — the doc's accounting
  unit is the spec; note that spec numbers refer to the matrix below.
- Soften "fully covers the 12 pure-backend workspaces" to load + API
  surface: scaffolder-backend-module-kubernetes also has a UI e2e that
  needs the render harness, so "fully" overstated the native-smoke scope.
- Replace short commit hashes and the fork-only
  RHIDP-13235-layer3-component-tests branch name with the durable PR
  reference (rhdh#4864, closed) — hashes on a mutable branch dangle after
  a rebase or branch deletion.
- Give DRAFT a promotion condition (groomed into RHIDP-13528/13529).
- Link the matrix from docs/e2e-tests/README.md ("Adding a Test") so the
  doc is discoverable outside the Jira comment.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions

github-actions Bot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

The container image build workflow finished with status: cancelled.

@sonarqubecloud

sonarqubecloud Bot commented Jul 2, 2026

Copy link
Copy Markdown

@github-actions

github-actions Bot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Image was built and published successfully. It is available at:

### Tally

| Target | Count | Specs |
| -------------- | ----- | ------------------------------------------- |

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The count says 9 but the Specs column lists 10 entries (#3 through #12), and the column sums give 4+9+5+11=29 while the matrix heading says 30. If #3 only half-counts because of the smoke footnote, shouldn't the count still be 10 with the asterisk carrying the caveat? This table feeds the RHIDP-13528/13529 batches, so the off-by-one propagates into ticket scoping.


## Update 2026-07-02 — L4a harness validation (RHIDP-15075, PR #5005)

(Spec numbers refer to the summary matrix below.)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only two specs are named here (#4 and #6) and only two rows in the matrix carry the green marker, so "4 of these tests" reads as 4 specs at first pass. If it's 4 test cases inside those 2 spec files, maybe say "runs 2 specs (4 test cases) green in CI"?

### Recommendation for the overlay repo (feeds RHIDP-13530 / RHDHPLAN-525)

Build **two harnesses**, not one Docker fixture:

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scaffolder-backend-module-kubernetes is in this "fully covers" list, but it also sits in the "Frontend UI e2e (24)" bucket below where startTestBackend is explicitly insufficient, and in tier B of the cluster-coupling table. Should this read "covers the load + API surface of" instead of "fully covers", or does that workspace not belong in the pure-backend list? Whoever picks up RHIDP-13530 will use these buckets as a work breakdown.

land.

Note: #19 `plugin-dynamic-loading` ships with PR #4967, which is still **open** — the
row below describes its state once merged.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Both numbers are right, but the 29-vs-30 reconciliation (#19 pending in #4967) lives a screen above this heading — anyone landing here via anchor link only sees the mismatch with the "all 29 specs on main" line. Maybe "(30 specs: 29 on main + #19 pending in #4967)" right in the heading?

RHIDP-13235 (Layer 3 component tests), carried by PR #4864. These prove the pattern
works and should be the template for the rest (the PR is the durable reference — its
branch may be rebased or deleted):

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These short hashes point at an unmerged branch — one rebase or force-push and they're dangling, and once the branch is deleted after merge GC can drop the commits entirely. Since this doc is meant to outlive the branch, referencing the test file paths (or the eventual PR number) would stay resolvable.

@@ -0,0 +1,274 @@
# E2E → Lower-Layer Migration Matrix (Phase 1)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now the only path to this doc is the Jira comment that references it — docs/e2e-tests/README.md doesn't link it and no index picks it up. A one-line link from the e2e-tests README (or CI.md, which covers test strategy) would finish the discoverability goal from the PR description.

**Story**: RHIDP-15076 — Identify E2E specs supplementable by Layer 3 / cluster-free harness (Phase 1)
**Author**: Gustavo Lira e Silva
**Date**: 2026-06-26 (updated 2026-07-02 with L4a harness validation results)
**Status**: DRAFT — promote once the batches below are groomed into RHIDP-13528/13529

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Docs merged as DRAFT tend to stay DRAFT forever — what promotes this one? Either drop the status line (merging is the publication event) or state the condition, e.g. "DRAFT until RHIDP-13528/13529 are groomed".

- _Needs full app but only GitHub/IdP (no cluster infra)_ → **L4a** now; **L2/L3** only if the external call is mocked
- _Needs real cluster / managed DB / real IdP / ConfigMap reload_ → **stays L4b**

## Update 2026-07-02 — L4a harness validation (RHIDP-15075, PR #5005)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: This section leans on #4, #5, #7, #8, #9 before the matrix that defines those numbers appears below. Moving the update after the matrix — or adding "(spec numbers refer to the summary matrix below)" at the top — would help first-time readers, who are the audience of a Phase-1 deliverable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant