Migrate syncPending to ReleasePayloads

[bradmwilliams]

Refactored syncPending(), in the release-controller, to determine the state of the release creation to the ReleasePayload CRD instead of computing it locally from the batch job itself.

rh-pre-commit.version: 2.4.0
rh-pre-commit.check-secrets: ENABLED

Summary by CodeRabbit

• Bug Fixes
  • Improved release progression so pending releases advance based on their actual release phase, reducing cases of stalling or incorrect completion.
  • Enhanced failure handling so failed releases transition sooner and include clearer termination details.
  • Maintained changelog pre-caching when releases reach the ready phase.
• Refactor
  • Streamlined the ready/failure workflow by reusing the same phase-driven logic across stable and non-stable pending tags.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 1f6128a3-fa46-4167-a7c9-c99adb282f1e

📥 Commits

Reviewing files that changed from the base of the PR and between 100bb3a and 318a841.

📒 Files selected for processing (1)

• cmd/release-controller/sync.go

---

📝 Walkthrough

Walkthrough

syncPending now drives both stable and non-stable pending-tag transitions from ReleasePayload phase values. Stable handling also extracts changelog pre-caching into a helper, and failure paths now retrieve termination-message details before transitioning.

Changes

Release payload phase handling

Layer / File(s)	Summary
Stable pending phase switch cmd/release-controller/sync.go	After import/rewrite job creation, the stable pending path reads the ReleasePayload, branches on Ready, Failed, or default, and moves changelog pre-caching into precacheChangelog.
Non-stable pending phase switch cmd/release-controller/sync.go	The non-stable pending path now branches on ReleasePayload phase instead of job completion checks, with Ready, Failed, and default handling updated accordingly.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Suggested labels:tide/merge-method-squash

Suggested reviewers:hoxhaeris, AlexNPavel

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main refactor: syncPending now derives release state from ReleasePayloads.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

cmd/release-controller/sync.go (1)

377-409: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Duplicated changelog pre-cache goroutine across both Ready branches.

The SortedRawReleaseTags + goroutine block that pre-caches the changelog is identical in the stable Ready branch (Lines 381-409) and the non-stable Ready branch (Lines 461-489). Consider extracting a helper (e.g., c.precacheChangelog(release, tag)) to remove the duplication and keep the two paths from drifting.

Also applies to: 457-489

🤖 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 `@cmd/release-controller/sync.go` around lines 377 - 409, The changelog
pre-cache logic is duplicated in both Ready branches of sync handling, so factor
the repeated SortedRawReleaseTags plus goroutine block into a shared helper on
the controller, such as c.precacheChangelog(release, tag), and call it from both
releasecontroller.ReleasePhaseReady paths. Keep the helper responsible for the
same pullspec lookup, GetImageInfo calls, and ChangeLog pre-cache behavior so
the two branches stay consistent and don’t drift.

🤖 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.
Inline comments:
In `@cmd/release-controller/sync.go`:
- Around line 410-413: The stable ReleasePhaseFailed path in syncRelease is
dropping the underlying failure diagnostics and should be aligned with the
non-stable Failed branch. Update the ReleasePhaseFailed case to retrieve the job
termination message using ensureJobTerminationMessageRetrieved and wrap the
result with withLog, then pass that richer message into
transitionReleasePhaseFailure instead of the bare reasonAndMessage call. Keep
the behavior consistent with the non-stable failure handling so both branches
preserve the same debugging context.
- Around line 371-374: The ReleasePayload lookup in ensureReleasePayload is
treating a lister NotFound as a hard error, which can happen before the cache
catches up. Update the Get(tag.Name) error handling in ensureReleasePayload to
detect errors.IsNotFound(err) and follow the normal pending/default wait path
instead of returning, while preserving existing behavior for other errors.
---
Nitpick comments:
In `@cmd/release-controller/sync.go`:
- Around line 377-409: The changelog pre-cache logic is duplicated in both Ready
branches of sync handling, so factor the repeated SortedRawReleaseTags plus
goroutine block into a shared helper on the controller, such as
c.precacheChangelog(release, tag), and call it from both
releasecontroller.ReleasePhaseReady paths. Keep the helper responsible for the
same pullspec lookup, GetImageInfo calls, and ChangeLog pre-cache behavior so
the two branches stay consistent and don’t drift.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 90add904-70f9-4689-a484-b5bdf574e9a2

📥 Commits

Reviewing files that changed from the base of the PR and between 63677de and 100bb3a.

📒 Files selected for processing (1)

• cmd/release-controller/sync.go

[openshift-ci]

@bradmwilliams: all tests passed!

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.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: AlexNPavel, bradmwilliams

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [AlexNPavel,bradmwilliams]

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