fix(e2e): assert Topology Ingress rules content on release-1.9

[rostalan]

Backport the main-branch Ingress assertion fix #4774 so GKE nightlies validate the rendered ingress.spec (service backend) instead of full K8s YAML fields.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rhdh-qodo-merge]

PR Summary by Qodo

Fix Topology e2e Ingress assertion to validate rendered ingress.spec backend

🐞 Bug fix 🧪 Tests 🕐 10-20 Minutes

AI Description

• Backport Topology e2e fix to assert Ingress rule content instead of full K8s YAML.
• Stabilize GKE nightly runs by checking for the service backend name in the rendered code block.

Diagram

graph TD
  A["Playwright test"] --> B["Topology page"] --> C["Ingress list (testid)"] --> D["Ingress code block"] --> E["Assert: service name"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Assert on parsed structure (JSON/spec model)

• ➕ More robust than string matching; less sensitive to formatting/whitespace changes
• ➕ Can target exact fields like rules/http/paths/backend
• ➖ Requires the UI/test to expose a structured representation (or parsing logic in test)
• ➖ Higher implementation overhead for a small backport fix

2. Assert only on presence of the code block (no content)

• ➕ Very stable across rendering changes
• ➕ Minimal maintenance
• ➖ Misses regressions where ingress content is incorrect or empty
• ➖ Doesn't validate the original bug scenario (backend rendering)

3. Fetch and assert via API instead of UI text

• ➕ Avoids UI formatting fragility
• ➕ Can validate the source ingress.spec directly
• ➖ Stops being a true e2e UI assertion (doesn't validate what users see)
• ➖ Needs environment-specific endpoint/auth wiring in tests

Recommendation: Current approach is the best tradeoff for a backport: assert a stable, user-visible semantic string (service backend name) rather than brittle full-YAML markers. It keeps the test e2e-focused while avoiding flakiness from cluster/provider-specific YAML fields.

Files changed (1) +4 / -4

Tests (1) +4 / -4

topology.spec.tsMake Ingress assertion check rendered backend service name +4/-4

Make Ingress assertion check rendered backend service name

• Replaces a broad assertion that looked for generic Kubernetes YAML keys with a targeted assertion against the Ingress list code block. The test now validates the rendered ingress.spec includes the expected backend service name (topology-test-service), reducing provider-specific flakiness.

e2e-tests/playwright/e2e/plugins/topology/topology.spec.ts

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (1)

Context used

✅ Compliance rules (platform): 46 rules

✅ Skills: e2e-verify-fix, e2e-diagnose-and-fix

✅ Cross-repo context

  Not relevant to this PR: redhat-developer/rhdh-plugins

  Not relevant to this PR: redhat-developer/rhdh-chart

  Not relevant to this PR: redhat-developer/rhdh-operator

  Not relevant to this PR: redhat-developer/rhdh-local

1. Unscoped ingress code check 🐞 Bug ☼ Reliability

Description

testIngressResources() verifies the presence of the 'topology-test-route' ingress link but then
asserts against the first <code> block in the entire ingress list, which can validate the wrong
ingress entry when multiple ingresses are shown. This can cause false failures or false confidence
depending on list ordering and which ingress renders first.

Code

e2e-tests/playwright/e2e/plugins/topology/topology.spec.ts[R121-124]

+  // Verify ingress configuration code block shows service backend (not full K8s YAML)
+  const ingressCode = page.getByTestId("ingress-list").locator("code").first();
+  await expect(ingressCode).toBeVisible();
+  await expect(ingressCode).toContainText("name: topology-test-service");

Relevance

⭐⭐⭐ High

Likely real flake/false-positive risk; teams usually accept tightening E2E assertions to correct
item.

PR-#4437

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The test independently locates the ingress link and then selects the first code block within the
whole ingress list, so the assertion is not guaranteed to be tied to the intended ingress entry.
Additionally, CI config shows an ingress is created for Developer Hub and commonLabels apply
backstage.io/kubernetes-id: developer-hub, and the topology-test ingress uses the same
kubernetes-id label, making it plausible for multiple ingresses to be present under the same entity
scope.

e2e-tests/playwright/e2e/plugins/topology/topology.spec.ts[112-125]
.ci/pipelines/value_files/values_showcase.yaml[351-356]
.ci/pipelines/value_files/values_showcase.yaml[443-445]
.ci/pipelines/resources/topology_test/topology-test-ingress.yaml[1-19]

Agent prompt

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

### Issue description
`testIngressResources()` checks for the `topology-test-route` link but then reads `locator("code").first()` from the entire `ingress-list`. If more than one ingress is rendered in that list, the code assertion may target a different ingress than the one identified by the link.

### Issue Context
The CI Helm values configure an ingress for Developer Hub and apply `backstage.io/kubernetes-id: developer-hub` as a common label to chart resources, while the topology-test ingress uses the same kubernetes-id label. This makes it plausible for multiple ingresses to appear under the same entity/resources view.

### Fix Focus Areas
- e2e-tests/playwright/e2e/plugins/topology/topology.spec.ts[112-125]

### Suggested change
Scope the code-block locator to the specific ingress entry that contains the `topology-test-route` link (example patterns):

```ts
const ingressList = page.getByTestId("ingress-list");
const ingressLink = ingressList.getByRole("link", { name: "topology-test-route" }).first();

// Pick the closest container for that ingress entry, then find its code block.
const ingressEntry = ingressLink.locator("xpath=ancestor::*[self::tr or self::li or self::div][1]");
const ingressCode = ingressEntry.locator("code");

await expect(ingressCode).toBeVisible();
await expect(ingressCode).toContainText("name: topology-test-service");
```

(Adjust the ancestor selector to match the actual markup, e.g., a table row, list item, or card container.)

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

---

2. CSS locator("code") used 📜 Skill insight ✧ Quality

Description

The E2E spec uses a raw CSS selector via locator("code") instead of a semantic Playwright locator,
which can make the test more brittle and harder to maintain. Prefer semantic locators (e.g.,
getByText/getByRole scoped under getByTestId) where possible.

Code

e2e-tests/playwright/e2e/plugins/topology/topology.spec.ts[122]

+  const ingressCode = page.getByTestId("ingress-list").locator("code").first();

Relevance

⭐⭐ Medium

Semantic-locator preference is plausible, but code blocks often require CSS locators; unclear if
change is feasible/valued.

PR-#4680
PR-#4437

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1699 requires preferring semantic Playwright locators over CSS/XPath selectors. The
added line uses locator("code"), a CSS selector, to find the ingress configuration block.

e2e-tests/playwright/e2e/plugins/topology/topology.spec.ts[122-122]
Skill: e2e-diagnose-and-fix

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 test uses `page.getByTestId("ingress-list").locator("code")`, which relies on a raw CSS selector. The compliance requirement is to prefer semantic Playwright locators wherever possible.

## Issue Context
This change is in an E2E spec file and should use stable, semantic locators (scoped under `getByTestId` if needed) rather than CSS selectors.

## Fix Focus Areas
- e2e-tests/playwright/e2e/plugins/topology/topology.spec.ts[122-124]

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

---

[rostalan]

/test ?

[rostalan]

/test

[rostalan]

/test e2e-gke-helm-nightly

[github-actions]

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

• quay.io/rhdh-community/rhdh:pr-5174
• quay.io/rhdh-community/rhdh:pr-5174-047c913f

[rostalan]

ran ci/prow/e2e-gke-helm-nightly, green

[djanickova]

LGTM