Repository navigation
Conversation
Signed-off-by: Ankita Thomas <ankithom@redhat.com>
Signed-off-by: Chris Moore <cmoore@redhat.com>
…rry-pick-1357-to-release-5.0 [release-5.0] OCPBUGS-113283: force node arch for opm and catalogsource pod for multiarch tests; fix test failure
…cy cases Signed-off-by: grokspawn <jordan@nimblewidget.com>
…rry-pick-1359-to-release-5.0 [release-5.0] OCPBUGS-83412: set catalogsource spec.grpcpodconfig.scc: restricted for all non-legacy cases
incompatibleOperators lists the CSVs from the informer cache. The cache returns them in map order, which changes between reconciles. skews.String() kept that order, so the same set of blocking CSVs produced different messages. conditionsEqual compares the message, so each reorder counted as a condition transition: the controller rewrote the ClusterOperator status and moved lastTransitionTime although nothing had changed. With two blocking CSVs on OCP 4.22 the message alternated between the two orders every one to two minutes. skews.String() now sorts a copy of the skews before it builds the message: skews with a property error first, as before, then by namespace and name. The same set of CSVs gives the same message in any input order, so the condition only transitions when the set changes. The regression test feeds three skews in three orders and expects one message. It fails on the previous implementation, which filled the non-error entries from the end of the slice. Fixes OCPBUGS-129618 Signed-off-by: Harald Klein <hklein@redhat.com> Co-Authored-By: Claude <noreply@anthropic.com>
…48)" This reverts commit 73a2205759278f98a4407bd0d07f166c5445a7bc (Hard-code version upgrade message for 4.22 upgrade paths, 2026-01-26, #3748). That change was an acceptable hack for 4.22 controllers, but should never have landed in the development branch, where it's currently generating output like: ClusterServiceVersions blocking minor version upgrades to 4.23 or major version upgrades to 5.0 in 5.0 clusters [1]. [1]: https://redhat.atlassian.net/browse/OPRUN-4431?focusedCommentId=17613550
While "it is safe to ignore the error here" would be nice, and may work for flows coming from an incompatibleOperators call, it's a brittle assumption. For example, it breaks down in TestSkewsStringIsDeterministic, which had been running skew.String() and skews.String() without either populating .err. In this commit, I'm making sure we've evaluated for errors in any code path that leads to those String() calls. This may make some code-paths slightly less efficient, by parsing the same valid skew version multiple times. But parsing a skew version isn't that expensive, so I'm not worried about a few CPU cycles there.
|
Pipeline controller notification This PR uses the pipeline controller for second-stage tests. Selection and triggering follow the repository configuration. Use |
|
Caution Review failedThe pull request is closed. Finishing Touches
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: wking The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
darn it, I meant to open against 5.0. Closing to try again... |
|
re-opened against |
Manually carrying operator-framework/operator-lifecycle-manager#3955 back to the 5.0 branch here. The 5.1 branch will presumably be covered later in an automatic rebase on upstream development, after the upstream pull merges. Generated by:
all of which applied cleanly, as of this upstream tip: