OCPQUAL-20: Refresh retry allowlist against 5.0 and 5.1 CI data - #31551
OCPQUAL-20: Refresh retry allowlist against 5.0 and 5.1 CI data#31551mkowalski wants to merge 1 commit into
Conversation
Refresh pkg/test/ginkgo/retry_allowed_tests.yaml against current retry
statistics (last 30 days, >= 5 flakes). A test is kept only if it still
flakes at or above the threshold in release 5.0 or 5.1; entries that no
longer qualify in either release are removed. This drops 26 tests,
leaving 97 (down from 123).
origin/main now targets 5.1, so the documented candidate query is widened
to variant_value IN ('5.0', '5.1'). Keeping a test that still flakes on
5.1 preserves its retry eligibility even after it has gone quiet in 5.0,
avoiding first-attempt failures on main. This is a removals-only refresh:
newly qualifying tests are added only after review, not automatically.
Assisted-By: claude-opus-4-8
Signed-off-by: Mat Kowalski <mko@redhat.com>
|
Pipeline controller notification For optional jobs, comment This repository is configured in: automatic mode |
|
@mkowalski: This pull request references OCPQUAL-20 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 task to target the "5.1.0" version, but no target version was set. DetailsIn response to this:
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. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. WalkthroughThe retry-eligible test list now uses a 5.0 and 5.1 candidate query. The list removes obsolete tests and adds or retains qualifying OAuth, CLI, DevEx, image-registry, and build candidates. ChangesRetry-eligible test list
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This PR refreshes the retry allowlist by removing tests that no longer meet the stated flake threshold; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mkowalski The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/cc @dgoodwin |
|
Scheduling required tests: |
|
@mkowalski: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
What
Refreshes
pkg/test/ginkgo/retry_allowed_tests.yamlagainst current CI retrystatistics (last 30 days, >= 5 flakes threshold).
5.1 CI, leaving 97 tests (down from 123).
origin/mainnow targets 5.1, the documented candidate query iswidened to
variant_value IN ('5.0', '5.1'). A test keeps its retryeligibility if it still flakes >= 5 times in either release, so tests still
flaking on
main(5.1) are not dropped even if they have gone quiet in 5.0.Why
The allowlist is intended to shrink over time as flaky tests are fixed.
Regenerating from current data drops tests that no longer flake, so they must
pass on the first attempt again. Widening the candidate set to 5.0 + 5.1 avoids
removing retry eligibility from tests that are still flaking on the release
mainnow runs against. Newly qualifying tests are added only after review, notautomatically, so this refresh only ever removes entries.
This PR was generated using AI. Please verify before acting on it.
Summary by CodeRabbit