Bump kubernetes-client-bom from 6.13.1 to 6.13.3

[manusa]

Kubernetes Client 6.13.3 was just released: https://github.com/fabric8io/kubernetes-client/releases/tag/v6.13.3

Kubernetes Client 6.13.2 was just released: https://github.com/fabric8io/kubernetes-client/releases/tag/v6.13.2

Related to #39934

/cc @metacosm

[gsmet]

@metacosm I let you check this one.

[metacosm]

PR doesn't build in CI: https://github.com/quarkiverse/quarkus-operator-sdk/actions/runs/10332967104/job/28604798710#step:9:37275
Any idea what's going on?

[gsmet]

@metacosm my guess is that the version of Maven you use is too old (GitHub is known for shipping an old default version). Use ./mvnw to build Quarkus.

[metacosm]

This is no-go for us at the moment. We're seeing issues similar to fabric8io/kubernetes-client#6249 with the upgrade. See https://github.com/quarkiverse/quarkus-operator-sdk/actions/runs/10356102901/job/28665238089#step:18:696

[metacosm]

Note that this is an example of why version checking alignment was introduced in QOSDK: a patch version discrepancy between Quarkus, JOSDK and QOSDK breaks end user apps and this is why some of our users wanted to be able to fail a build if such a situation was detected.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit cda2640.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[gastaldi]

Ah crap, I didn't see the comments, I'm going to revert this, sorry for the trouble.

Actually, I am confused as the tests did pass, should we revert this @metacosm @gsmet? According to the conversation in fabric8io/kubernetes-client#6249 it seems to be okay?

[manusa]

Note that @metacosm comments are related to 6.13.2 (prior to my last commit that bumps to 6.13.3).

Supposedly 6.13.3 addresses the issue mentioned by Chris.

I'd wait for his comments before reverting because this might be already alright.

[metacosm]

No need to revert.

Ah crap, I didn't see the comments, I'm going to revert this, sorry for the trouble.

Actually, I am confused as the tests did pass, should we revert this @metacosm @gsmet? According to the conversation in fabric8io/kubernetes-client#6249 it seems to be okay?

The problem is that the Quarkus tests passing doesn't mean that things are OK as they do not cover many things that can break. I don't pretend that the tests QOSDK does cover all these things either but at least, they do exercise the Kubernetes support in Quarkus some more 😅. Using passing tests here does not presume of things not being broken elsewhere (in particular in QOSDK), which is why we're asking to be asked before the Fabric8 client is updated in Quarkus.

That said, https://github.com/quarkiverse/quarkus-operator-sdk/actions/runs/10373264251/job/28717966233 seems to indicate that, indeed, the initial issue we found with 6.13.2 is addressed. Now, it would be nice to figure out why the issue was happening in the first place since that hasn't been fixed (6.13.3 relies on method overloading to bypass the underlying issue).

It would be nice to have some more automated way to perform these checks (currently this relies on a manual process) and stricter gates to prevent merging when things are not supposed to be. At the very least, updates to the Fabric8 client shouldn't be merged without an approval of the PR by someone from the QOSDK team.