🌱 Bump helm to 3.14.1#823
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #823 +/- ##
=======================================
Coverage 35.27% 35.27%
=======================================
Files 9 9
Lines 808 808
=======================================
Hits 285 285
Misses 479 479
Partials 44 44 ☔ View full report in Codecov by Sentry. |
kevinrizza
force-pushed
the
update-helm-dep
branch
from
3cfaa08 to
6a8a84c
Compare
|
@kevinrizza I haven't looked into this properly, but I have a feeling that the e2e failures are legit. Most likely we assert (for whatever reason) error messages which got changed. |
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
Also bumps kubernetes dependencies to 1.29 Signed-off-by: kevinrizza <krizza@redhat.com> Signed-off-by: Mikalai Radchuk <mradchuk@redhat.com>
m1kola
force-pushed
the
update-helm-dep
branch
from
945f9dc to
7d9574e
Compare
|
I'm taking over this PR (with Kevin's permissions). I updated the branch and I think we should be good now. |
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
varshaprasad96
left a comment
varshaprasad96
left a comment
There was a problem hiding this comment.
The changes look good, and all the tests pass.
/lgtm
/approve.
Just a small question regarding the change in error.
| WithTransform(func(c *metav1.Condition) metav1.ConditionStatus { return c.Status }, Equal(metav1.ConditionFalse)), | ||
| WithTransform(func(c *metav1.Condition) string { return c.Reason }, Equal(rukpakv1alpha2.ReasonInstallFailed)), | ||
| WithTransform(func(c *metav1.Condition) string { return c.Message }, ContainSubstring(`the server could not find the requested resource`)), | ||
| WithTransform(func(c *metav1.Condition) string { return c.Message }, ContainSubstring(`no matches for kind "CatalogSource" in version "operators.coreos.com/v1alpha1"`)), |
There was a problem hiding this comment.
Though no matches for the kind and could not find the resources return the same HTTP error code, I believe the former means that the CRD is not installed available in the cluster (API server does not know the definition), whereas the latter indicates that the specific resource endpoint does not exist. Was there a change in k8s because of which this change was needed? Just curious.
There was a problem hiding this comment.
@varshaprasad96 I believe that both errors were about missing CRDs originally. I think so because:
- Full text of original error suggests this (complaining about missing group version, see examples below)
- Test data for these two cases does not have these CRDs, but has CRs.
There was a number of breaking changes in controller-runtime@v0.17.0. I think most likely this is due to kubernetes-sigs/controller-runtime#2571.
Original errors:
error while running post render on files: postrenderer[0] (*client.ownerPostRenderer) failed: unable to recognize "": failed to get API group resources: unable to retrieve the complete list of server APIs: operators.coreos.com/v1: the server could not find the requested resource
error while running post render on files: postrenderer[0] (*client.ownerPostRenderer) failed: unable to recognize "": failed to get API group resources: unable to retrieve the complete list of server APIs: operators.coreos.com/v1alpha1: the server could not find the requested resource
3 participants
Also bumps kubernetes to 1.29