TRT-2762: Component Readiness: adding variant filter inflates regression count with unrelated results

[openshift-trt-agent]

Summary

Fixes TRT-2762: Adding a variant filter in Component Readiness inflated the regression count with unrelated results (from ~86 to 400+).

Two bugs were identified and fixed in sippy-ng/src/component_readiness/CompReadyVars.js:

1. Missing test_filters sync in updateVarsFromView(): When a view was selected, updateVarsFromView() synced variant options and advanced options into React state but skipped test_filters (lifecycles, capabilities). When the user clicked "Generate Report", the view URL param was dropped and explicit params were built from React state. Since lifecycles was never synced to state, the filter was lost. The lifecycles filter is applied only to the sample query (not the base), so losing it caused all lifecycle tests to appear in the sample, producing hundreds of spurious regressions. This fix adds syncing of test_filters.lifecycles and test_filters.capabilities from the view config into React state.

2. State mutation bug in variant replace functions: replaceIncludeVariantsCheckedItems() and replaceCompareVariantsCheckedItems() mutated the existing state object directly (includeVariantsCheckedItems[variant] = checkedItems) then called the setter with the same object reference. React relies on reference equality to detect state changes, so this mutation was invisible to React and could cause stale renders. This fix creates a new object with the spread operator before calling the setter.

Test plan

• make lint passes
• make test passes (Go + Jest)
• E2e tests: 107/108 passed; the single failure (TestRegressionCacheLoader) is a pre-existing BigQuery credentials issue unrelated to this change
• Verified in browser with seed data: loading a view and clicking "Generate Report" preserves the regression count (5 regressed components before and after)
• Code review: confirmed that updateVarsFromView now syncs all filter categories (variant_options, test_filters, advanced_options)
• Code review: confirmed both variant replace functions now create new state objects

---

Generated with Claude Code

[openshift-merge-bot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: automatic mode

[openshift-ci-robot]

@openshift-trt-agent[bot]: This pull request references TRT-2762 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

Fixes TRT-2762: Adding a variant filter in Component Readiness inflated the regression count with unrelated results (from ~86 to 400+).

Two bugs were identified and fixed in sippy-ng/src/component_readiness/CompReadyVars.js:

1. Missing test_filters sync in updateVarsFromView(): When a view was selected, updateVarsFromView() synced variant options and advanced options into React state but skipped test_filters (lifecycles, capabilities). When the user clicked "Generate Report", the view URL param was dropped and explicit params were built from React state. Since lifecycles was never synced to state, the filter was lost. The lifecycles filter is applied only to the sample query (not the base), so losing it caused all lifecycle tests to appear in the sample, producing hundreds of spurious regressions. This fix adds syncing of test_filters.lifecycles and test_filters.capabilities from the view config into React state.

2. State mutation bug in variant replace functions: replaceIncludeVariantsCheckedItems() and replaceCompareVariantsCheckedItems() mutated the existing state object directly (includeVariantsCheckedItems[variant] = checkedItems) then called the setter with the same object reference. React relies on reference equality to detect state changes, so this mutation was invisible to React and could cause stale renders. This fix creates a new object with the spread operator before calling the setter.

Test plan

• make lint passes
• make test passes (Go + Jest)
• E2e tests: 107/108 passed; the single failure (TestRegressionCacheLoader) is a pre-existing BigQuery credentials issue unrelated to this change
• Verified in browser with seed data: loading a view and clicking "Generate Report" preserves the regression count (5 regressed components before and after)
• Code review: confirmed that updateVarsFromView now syncs all filter categories (variant_options, test_filters, advanced_options)
• Code review: confirmed both variant replace functions now create new state objects

---

Generated with Claude Code

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: openshift-trt-agent[bot]
Once this PR has been reviewed and has the lgtm label, please assign deads2k for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @openshift-trt-agent[bot]. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[stbenjam]

/ok-to-test

[stbenjam]

/test agentic-staging

[openshift-merge-bot]

Scheduling required tests:
/test e2e

[stbenjam]

/test agentic-staging

[openshift-trt-agent]

Sippy Staging Environment

URL: https://vat-salad-sox-psychiatry.trycloudflare.com

This environment is built from this PR and will remain available for approximately 60 minutes (until ~14:10 UTC).

[stbenjam]

Hm, I don't think this is working.

For example this URL:

https://vat-salad-sox-psychiatry.trycloudflare.com/sippy-ng/component_readiness/main?baseEndTime=2026-05-30%2023%3A59%3A59&baseRelease=4.21&baseStartTime=2026-04-30%2000%3A00%3A00&columnGroupBy=Network%2CPlatform%2CTopology&confidence=95&dbGroupBy=Architecture%2CFeatureSet%2CInstaller%2CLayeredProduct%2CNetwork%2CPlatform%2CSuite%2CTopology%2CUpgrade&flakeAsFailure=false&ignoreDisruption=true&ignoreMissing=false&includeMultiReleaseAnalysis=true&includeVariant=Architecture%3Aamd64&includeVariant=Architecture%3Aarm64&includeVariant=FeatureSet%3Adefault&includeVariant=FeatureSet%3Atechpreview&includeVariant=Installer%3Aipi&includeVariant=LayeredProduct%3Anone&includeVariant=Network%3Aovn&includeVariant=Platform%3Aaws&includeVariant=Platform%3Agcp&includeVariant=Suite%3Aparallel&includeVariant=Suite%3Aserial&includeVariant=Suite%3Aunknown&includeVariant=Topology%3Aha&includeVariant=Upgrade%3Amicro&includeVariant=Upgrade%3Aminor&includeVariant=Upgrade%3Anone&minFail=3&passRateAllTests=0&passRateNewTests=90&pity=5&sampleEndTime=2026-06-29%2023%3A59%3A59&samplePRNumber=&samplePROrg=&samplePRRepo=&sampleRelease=4.22&sampleStartTime=2026-06-26%2000%3A00%3A00&testCapabilities=install

should not even be showing me cap1 regressions, but it does.

Seeded data should include some things not selected in the default view as well, so we can better test this fix.

[openshift-trt-agent]

@stbenjam Good catch. The root cause was that the PostgreSQL data provider was not filtering by testCapabilities at all -- the BigQuery provider had the correct filtering, but the PG provider (used with seed data) was missing it entirely.

Changes in this push:

1. PostgreSQL capability filtering (provider.go): Added capability intersection filtering to queryTestStatus(). When testCapabilities is specified in the request, only tests whose capabilities overlap with the requested set are included. This matches the BigQuery provider's existing behavior.

2. Seed data improvements (seed_data.go): Added a Platform:azure job and a networking-capability test that are NOT included in the default seed view (Platform:aws,gcp only). The ExtremeRegression test also runs on azure now. This means:

   • Default view correctly excludes azure results (variant filtering testable)
   • Adding testCapabilities=install correctly excludes cap1/networking results (capability filtering testable)

Verification:

• Default view: 5 regressed components, 13 total
• With testCapabilities=install: 0 regressed components, 1 component (comp-Install only, no cap1)
• With Platform:azure added to include_variants: azure results appear correctly
• E2e: 107/108 passed (1 pre-existing BigQuery credentials failure)

[openshift-merge-bot]

Scheduling required tests:
/test e2e

[openshift-ci]

@openshift-trt-agent[bot]: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/agentic-staging	4bc03a1	link	false	/test agentic-staging
ci/prow/e2e	54c1db7	link	true	/test e2e

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.