{{ message }}
fix(ui): wait for process events before timeline tests#21422
Draft
davdhacs wants to merge 7 commits into
Draft
Conversation
On a freshly deployed GKE cluster, process events may not be available immediately. The deployment/pod timeline tests that use real API data (no fixtures) fail because the timeline renders empty when no process events exist yet. Two-layer fix: 1. Workflow: poll /v1/processcount in the risk shard wait step until process events are detected (up to 5 minutes). 2. Cypress: add before() hooks in deploymentTimeline and podTimeline test files that poll /v1/processcount, ensuring data readiness even if the workflow-level wait was insufficient. Partially generated by AI. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## davdhacs/ui-e2e-gke-only #21422 +/- ##
=========================================================
Coverage 50.07% 50.07%
=========================================================
Files 2835 2835
Lines 217546 217546
=========================================================
+ Hits 108932 108939 +7
+ Misses 100708 100702 -6
+ Partials 7906 7905 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
🚀 Build Images ReadyImages are ready for commit bf53cfa. To use with deploy scripts: export MAIN_IMAGE_TAG=4.12.x-320-gbf53cfa89d |
The Cypress before() hook already waits for process events — the workflow-level wait is redundant. Keeps this PR as a pure test fix with no workflow file overlap with PR #21421. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
davdhacs
added a commit
that referenced
this pull request
Jun 25, 2026
Remove test changes from the workflow PR — test fixes belong in separate PRs. The network flow data wait in PR #21422 should make this test work without modifications. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
All vulnmanagement tests use real API data (not fixtures) and need image
CVE data from a completed scan to produce meaningful results. Add a
waitForImageCVEs() helper that triggers an nginx:1.12 scan and polls
GraphQL { imageCVECount } until > 0, matching the pattern established by
waitForProcessEvents() for timeline tests.
Added before() hooks to the 9 vulnmanagement test files that query image
CVE data: dashboard, dashboardToEntityPage, clusters, deployments,
entitypages, imageComponents, imageCves, images, namespaces.
Not added to: clusterCves (platform CVEs only), nodeCves/nodeComponents/
nodes (node-level data only).
Analysis of other shards:
- vulnerabilities: all fixture-based (visitWorkloadCveOverview stubs
getImageCVEList), no wait needed
- networkGraph: tests check stackrox namespace deployments which are
always present, no wait needed
AI-assisted.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Test changes belong in separate PRs. Network graph tests don't need data waits — they check for platform deployments which are always present. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Network graph sidebar test failed on fresh GKE clusters because collector hadn't sent network flow data yet. Added waitForNetworkFlows() that polls the network graph API until collector has outgoing edges. Timeline tests failed because waitForProcessEvents() checked global process count (/v1/processcount) which passes immediately, but the specific deployment shown in the risk list had no timeline events yet. Replaced with deployment-specific polling via /v1/deploymentswithprocessinfo that verifies the first risk-sorted stackrox deployment has baseline statuses. Also increased timeout from 2m to 5m and interval from 5s to 10s to reduce API load during warm-up. AI-assisted. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Process events: use /v1/processcount (simpler, proven API) with 10-minute timeout and count > 10 threshold. The previous /v1/deploymentswithprocessinfo endpoint wasn't returning expected data. - Network flows: increase timeout to 10 minutes. - Both: increase polling interval to 15s to reduce log noise. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The graph topology takes longer to render on GKE after selecting a deployment. Increase from default 8s to 30s. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
On a freshly deployed GKE cluster, process events may not be available immediately after deployment. The deployment/pod timeline Cypress tests that use real API data (no fixtures) fail because the timeline renders empty when no process events have been collected yet by collector.
Two-layer fix:
/v1/processcountin the*risk*shard wait step until process events are detected (up to 5 minutes, 60 iterations at 5s each)before()hooks indeploymentTimeline.test.jsandpodTimeline.test.jsthat poll/v1/processcountviacy.request(up to 2 minutes), ensuring data readiness even if the workflow-level wait was insufficientThe
waitForProcessEvents()helper is added toRisk.helpers.jsand uses recursivecy.requestpolling withCypress.env('ROX_AUTH_TOKEN')for authentication.User-facing documentation
Testing and quality
Automated testing
How I validated my change
Dispatched UI E2E workflow run to verify timeline tests pass with real data on a fresh GKE cluster.