docs(test-plans): FLPATH-3254 E2E gap TCs (TC-36–TC-42)

[vkolodny]

Summary

• Trim auth test plan E2E gaps to TC-36 – TC-42 (CLI and JWT-negative cases removed from this plan)
• Block SP / instance happy path on FLPATH-4622; UI path on FLPATH-4645
• Fix POST /catalog-item-instances (HTTP 201), provider health_status, port convention (:8080 local / :9080 Ecosystem Jenkins)
• Add subsystem + E2E checklist tables with ❗ markers; document Jenkins dead --auth-enabled on run-e2e.sh
• Clarify TC-08 as control-plane API only

Out of scope here

• CLI auth → utilities#34 / cli#29
• Wrong audience / alg:none → ❗ should cover on TC-14/TC-15 (subsystem)

Test plan

• Review feedback addressed (Gloria / Chad)
• Confirm sanitization notice still holds
• Optional: pipeline fix for dead --auth-enabled; subsystem wrong-aud / alg:none follow-ups

[gciavarrini]

Disclaimer:
Since this is a md test plan written for AI agents, I used AI to help review it too.

[qodo-code-review]

PR Summary by Qodo

Auth test plan: add full-stack E2E gap TCs (TC-36–TC-42)

📝 Documentation 🕐 20-40 Minutes

AI Description

• Add TC-36–TC-42 full-stack E2E gap coverage for auth-enabled workflows.
• Document current P1 blockers, CI port remap, and Jenkins auth-toggle caveats.
• Clarify TC scope and refresh subsystem automation coverage/checklists.

Diagram

graph TD
  J["Ecosystem Jenkins"] --> U["Utilities E2E"] --> CP["DCM Control-plane"]
  UI["DCM UI/RHDH"] --> CP
  SP["Service Providers"] --> CP
  KC{{"Keycloak (OIDC/JWKS)"}} --> CP

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Split into a separate E2E test plan document

• ➕ Keeps control-plane/Helm plan stable and reduces document size/churn
• ➕ Allows E2E gaps to evolve independently (utilities/Jenkins/UI/SP focus)
• ➖ More places to look for auth readiness; harder to see end-to-end coverage gaps at a glance
• ➖ Requires ongoing cross-linking/renumbering coordination

2. Track gap TCs primarily in Jira/TestRail and keep only a short markdown pointer

• ➕ Better workflow for execution status, ownership, and evidence collection
• ➕ Reduces duplicated step-by-step instructions in markdown
• ➖ Loses a single, versioned, repo-local reference for developers
• ➖ Harder for reviewers to validate endpoint/port conventions and known pitfalls in one place

Recommendation: Keep the combined document approach (current PR) because it preserves a single, versioned source of truth that explicitly ties subsystem coverage to full-stack E2E gaps and documents concrete execution blockers. Revisit splitting into a standalone E2E plan only if TC-36+ grows substantially or diverges in ownership/execution cadence.

Files changed (1) +497 / -18

Documentation (1) +497 / -18

FLPATH-3254-dcm-authentication-test-plan.mdAdd TC-36–TC-42 full-stack E2E gap section and execution/automation checklists +497/-18

Add TC-36–TC-42 full-stack E2E gap section and execution/automation checklists

• Expands the auth test plan with a scoped split and a new TC-36–TC-42 section covering full-stack gaps (instance create under auth, SP register/health under auth, UI/RHDH M2M token flow, Jenkins ENABLE_DCM_AUTH smoke, and JWKS/Keycloak restart resilience). Clarifies TC-08 as control-plane API only, documents CI port remapping (8080→9080), and records current execution blockers (FLPATH-4622/FLPATH-4645) plus the Jenkins dead --auth-enabled flag risk. Updates automation coverage tables, adds a checklist with ❗ markers, and bumps version/metadata.

test-plans/FLPATH-3254-dcm-authentication-test-plan.md

[qodo-code-review]

Code Review by Qodo

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

1. TLS verification disabled in TCs ✓ Resolved 🐞 Bug ⛨ Security

Description

TC-39 and TC-40 use curl -k/-sk, which disables TLS certificate verification for HTTPS requests to
RHDH endpoints. This can mask certificate/trust misconfiguration and reduces the security signal of
the auth-related UI smoke checks.

Code

test-plans/FLPATH-3254-dcm-authentication-test-plan.md[R2101-2102]

+curl -sk -o /dev/null -w 'HTTP %{http_code}\n' \
+  https://<RHDH_HOST>/api/dcm/providers

Evidence

The added steps explicitly include curl -sk for HTTPS calls to /api/dcm/providers and /dcm,
which disables certificate verification.

test-plans/FLPATH-3254-dcm-authentication-test-plan.md[2098-2106]
test-plans/FLPATH-3254-dcm-authentication-test-plan.md[2132-2137]

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 new UI/RHDH steps use `curl -sk` (insecure) by default. This bypasses certificate verification and can hide real TLS/certificate issues during testing.

## Issue Context
These are auth-related smoke checks where TLS configuration problems are meaningful; if self-signed certs are expected, the plan should say so explicitly and prefer `--cacert` (or only use `-k` as a clearly labeled fallback).

## Fix Focus Areas
- test-plans/FLPATH-3254-dcm-authentication-test-plan.md[2098-2106]
- test-plans/FLPATH-3254-dcm-authentication-test-plan.md[2132-2137]

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

---

2. Version metadata mismatch ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The document header sets Version to 1.8 even though the Version History records the latest revision
as 1.8.1 on 2026-08-07. This makes it unclear what the current revision is and can cause people to
cite or execute the wrong version of the plan.

Code

test-plans/FLPATH-3254-dcm-authentication-test-plan.md[8]

+| **Version** | 1.8 |

Evidence

The header explicitly says Version 1.8, while the Version History records a newer 1.8.1 revision on
the same date, indicating the header was not updated to match the latest revision.

test-plans/FLPATH-3254-dcm-authentication-test-plan.md[5-12]
test-plans/FLPATH-3254-dcm-authentication-test-plan.md[2405-2419]

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 header metadata claims Version `1.8`, but the Version History shows the latest revision is `1.8.1` (same update date). This creates ambiguity about the current document revision.

## Issue Context
The PR adds a new `1.8.1` Version History entry while leaving the header at `1.8`.

## Fix Focus Areas
- test-plans/FLPATH-3254-dcm-authentication-test-plan.md[5-12]
- test-plans/FLPATH-3254-dcm-authentication-test-plan.md[2405-2419]

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

---

Context

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

Tip of the day

💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗