Use unambiguous retry suffix to prevent job name collisions - #799
Use unambiguous retry suffix to prevent job name collisions#799hoxhaeris wants to merge 1 commit into
Conversation
|
Warning Review limit reached
Next review available in: 30 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughVerification retry job names now use a ChangesVerification retry naming
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hoxhaeris 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 |
openshift-ci
Bot
added
the
approved
|
/hold |
openshift-ci
Bot
added
the
do-not-merge/hold
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
pkg/releasepayload/utils/release-verification-job-details_test.go (1)
50-52: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valuePreserve test coverage for the old suffix format.
Since the regex patterns are explicitly designed to support both the old (
-N) and new (-retry-N) suffix formats during the transition phase, consider preserving the original test cases and adding theretry-variations as new, separate test cases.Modifying the existing tests in-place removes the explicit test coverage that guarantees the backward compatibility claimed in the PR summary.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pkg/releasepayload/utils/release-verification-job-details_test.go` around lines 50 - 52, Preserve the existing test case in the release-verification job details tests for the legacy “-N” suffix format, and add a separate case covering the “-retry-N” format. Keep each case’s expected ReleaseVerificationJobDetails values aligned with its respective job name so both supported patterns remain explicitly tested.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@pkg/releasepayload/utils/release-verification-job-details_test.go`:
- Around line 50-52: Preserve the existing test case in the release-verification
job details tests for the legacy “-N” suffix format, and add a separate case
covering the “-retry-N” format. Keep each case’s expected
ReleaseVerificationJobDetails values aligned with its respective job name so
both supported patterns remain explicitly tested.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: b447a4ef-3848-4519-ab47-06eb04f368f3
📒 Files selected for processing (5)
cmd/release-controller/sync_verify.gocmd/release-controller/sync_verify_prow.gocmd/release-controller/sync_verify_prow_test.gopkg/releasepayload/utils/release-verification-job-details.gopkg/releasepayload/utils/release-verification-job-details_test.go
| } | ||
| } | ||
| // Postfix the name to differentiate it from the analysis jobs | ||
| prowJobName = prow.GenerateSafeProwJobName(fullProwJobName, aggregatorSuffix) |
There was a problem hiding this comment.
Can you make sure that this function has tests for this new suffix? Specifically on really long job names because this is literally adding 6 more characters and we need to make sure they resolve properly (which they should, but warrants a test).
f3235b7 to
c69a957
Compare
Verification job names ending in -<number> (e.g., driver-toolkit-10 for RHEL 10) collide with the retry naming convention (driver-toolkit-1 for retry 1). The regex parser in the release-payload-controller cannot distinguish them, causing job results to be silently dropped. Change the retry suffix from a bare number to retry-N format: driver-toolkit-1 (old: retry 1) driver-toolkit-retry-1 (new: retry 1) driver-toolkit-10 (RHEL 10 job, no longer ambiguous) The regex patterns accept both old and new formats during the transition period so in-flight prowjobs with old names still parse correctly.
c69a957 to
de754fa
Compare
|
@hoxhaeris: all tests passed! 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. |
2 participants
Summary
Verification job names ending in
-<number>(e.g.,driver-toolkit-10for RHEL 10) collide with the retry naming convention (driver-toolkit-1for retry 1). The regex parser in the release-payload-controller cannot distinguish them, causing job results to be silently dropped.This changes the retry suffix from a bare number to
retry-Nformat:driver-toolkit-1(old: retry 1)driver-toolkit-retry-1(new: retry 1)driver-toolkit-10(RHEL 10 job, no longer ambiguous)The regex patterns accept both old and new formats during the transition period so in-flight prowjobs with old names still parse correctly.
Summary by CodeRabbit
retry-<n>suffixes.retry-prefixes.