Upgrade can result in integration being rebuilt using the old integrationkit

[phantomjinx]

The e2e tests reveal that on occasion, eg. here, an upgade of camel-k can result in an existing integration being rebuilt with the existing (not-upgraded) integrationkit.

1 integrations have been rebuilt
    cli_upgrade_test.go:107: 
        Timed out after 300.020s.
        Expected
            <string>: kit-cakddkimeh84ri4ora90
        to equal
            <string>: kit-cakddkimeh84ri4ora8g

The problem, of course, is this only happens in the test suite occasionally, so it is difficult to pin-down due to not being a consistent error. Therefore, is this something to warrant enough concern to be investigated?

[squakez]

Interesting... we're talking about same stuff in #3341 I start thinking that the rebuild should build from scratch then...

[squakez]

I had a look at this. I did not manage to replicate the issue. Actually it happens that when we do a kamel rebuild after a Camel K operator upgrade, the Integration.Status is wiped and a new IntegrationKit build is triggered as well (as the new operator version dependencies are different from the old ones). Which is the method we're using in the E2E tests to ask for a rebuild after an upgrade is performed?

[phantomjinx]

This is where the olm upgrade tests starts the upgrade -> https://github.com/apache/camel-k/blob/main/e2e/namespace/upgrade/olm_upgrade_test.go#L120

[squakez]

Looks good then. FYI, I've noticed that from 1.8 to 1.9 we were suffering rebuilds issues, but the seems to be gone from 1.9 to 1.10(nightly). Was the original reported issue test upgrading from 1.8 to 1.9?

[phantomjinx]

I think this has now been resolved.