Feature request: Filtering out what is in the test repo/production index vs what is not

[epacific1]

Moved from red-hat-data-services/org-pulse-core#28 (originally filed by @thesarahberry)

User story: I am a manager and I would like to know what has successfully passed the package onboarding pipeline and is in the test repository. This way if something is Unassigned, I know not to assign it.

Suggested solution: Add a column to indicate "Test Repo - y/n" and if it's "Y", it is shown as green on the dashboard.

[claude]

Claude finished @epacific1's task in 6m 6s —— View job

---

Feature Analysis: Test Repo Availability Indicator

• Read the full issue and understand the request
• Investigate the releases execution pipeline codebase
• Understand the current data model and UI
• Propose an implementation approach
• Apply appropriate labels

---

Understanding

The request is to show whether a feature's packages have successfully passed the package onboarding pipeline and are available in the test repository (the PyPI Simple index at packages.redhat.com). This lets managers know whether an "Unassigned" feature still needs work or is already onboarded and shouldn't be reassigned.

Current State

The codebase already has most of the building blocks but they aren't wired together:

1. Package index queries — modules/product-builds/server/package-index.js can query packages.redhat.com to check if a package exists in the test repo (-test suffix) or production repo for any product version and variant. Currently only used by the manual Package Search view.

2. Execution pipeline features — modules/releases/server/execution/feature-store.js tracks RHAISTRAT features with child epics, but has no package availability data.

3. Package name extraction — modules/product-builds/server/version-map.js already has extractPackageFromEpic() that can pull package names from epic summaries.

4. Milestone detection — TrafficMap.vue already detects "Konflux onboarding" status from epic summaries via text matching, but doesn't verify against actual indexes.

Proposed Implementation

Add a "Test Repo" status field to the execution pipeline, visible as a column/badge showing whether each feature's packages are available in the test repository.

Key changes:

Area	Change
New server route	GET /api/modules/releases/execution/features/:key/repo-status — cross-references a feature's child epics against the package index to return per-package test/production repo availability
Periodic enrichment (optional)	A background sync that batch-checks all features' packages against the index and caches results in the feature store (new repoStatus field alongside existing metrics, aiReview, etc.)
OverviewView / FeatureTable	Add a "Test Repo" column showing a green checkmark (all packages found), yellow warning (partial), or gray dash (no packages detected)
FeatureTrackingTable	Same indicator added to the tracking view
Filters	Add a filter option to show only features that are/aren't in the test repo

Data flow:

Feature (RHAISTRAT) → child epics → extract package names
  → query packages.redhat.com/{version}/{variant}-test/simple/{package}/
  → cache result in feature store as repoStatus: { packages: [{name, inTestRepo, inProdRepo, checkedAt}] }

Trade-offs to Consider

1. Cross-module dependency — The package index query lives in product-builds, while the feature store lives in releases. Per project conventions, this would use the internal API pattern (localhost HTTP calls) with a requires declaration in module.json, or alternatively the query logic could be extracted to shared code.

2. Variant ambiguity — A feature may map to multiple variants (CUDA, ROCm, CPU, etc.). The check could either query all configured variants or focus on a default variant.

3. Package name detection — Extracting package names from JIRA epic summaries is heuristic. Some features may not have easily detectable package names. A fallback could be a manual mapping in the execution config.

4. Rate limiting — Batch-checking many packages against the index needs throttling. The existing package index cache (configurable TTL) helps here.

Next Steps

If this approach looks right, tag me in a comment with approval and I'll implement it. If you'd prefer a different scope (e.g., only the Package Tracker view in product-builds rather than the execution pipeline, or a simpler Jira-field-based approach), let me know and I'll adjust the plan.