bugfix(#5755): avoiding deadlock between builds with dependencies build order strategy

[lsergio]

Closes #5755

Release Note

Fixed dependencies build order strategy to avoid deadlocks

[squakez]

Thanks for the PR. I think the extra condition check you've added when the time is exactly equal should be enough to avoid the deadlock. I am not sure to understand why you're changing the rest of the algorithm. Also +1 on the unit tests.

[gansheer]

LGTM. Just a small question : wouldn't it be better to use defaults.DefaultRuntimeVersion instead of "3.8.1" in the tests ?

[squakez]

@lsergio please rebase with main. I have fixed the CI.

[squakez]

LGTM. Just a small question : wouldn't it be better to use defaults.DefaultRuntimeVersion instead of "3.8.1" in the tests ?

Yeah, @lsergio it would be good if you can change in order to maintain consistency with the default settings (and other tests using the same). Thanks!

[lsergio]

LGTM. Just a small question : wouldn't it be better to use defaults.DefaultRuntimeVersion instead of "3.8.1" in the tests ?

Yeah, @lsergio it would be good if you can change in order to maintain consistency with the default settings (and other tests using the same). Thanks!

Hi @squakez and @gansheer. When I do it, I get the following error while building:

# github.com/apache/camel-k/v2/pkg/apis/camel/v1
package github.com/apache/camel-k/v2/pkg/apis/camel/v1
	imports github.com/apache/camel-k/v2/pkg/util/defaults
	imports github.com/apache/camel-k/v2/pkg/util/log
	imports github.com/apache/camel-k/v2/pkg/apis/camel/v1: import cycle not allowed in test

It is not really clear for me why this is happening. :(
If someone can provide some hint, that would be great. I googled for the error and could not find anything helpful.
For the test purpose, though, the runtime versions could be anything. I could have called them "runtime-1" and "runtime-2", for example.

[gansheer]

LGTM. Just a small question : wouldn't it be better to use defaults.DefaultRuntimeVersion instead of "3.8.1" in the tests ?

Yeah, @lsergio it would be good if you can change in order to maintain consistency with the default settings (and other tests using the same). Thanks!

Hi @squakez and @gansheer. When I do it, I get the following error while building:

# github.com/apache/camel-k/v2/pkg/apis/camel/v1
package github.com/apache/camel-k/v2/pkg/apis/camel/v1
	imports github.com/apache/camel-k/v2/pkg/util/defaults
	imports github.com/apache/camel-k/v2/pkg/util/log
	imports github.com/apache/camel-k/v2/pkg/apis/camel/v1: import cycle not allowed in test

It is not really clear for me why this is happening. :( If someone can provide some hint, that would be great. I googled for the error and could not find anything helpful. For the test purpose, though, the runtime versions could be anything. I could have called them "runtime-1" and "runtime-2", for example.

If these does not need a real runtime version, then I would go with fake ones like you suggest.

[squakez]

It's a circular reference loop. Yeah, let's keep this way then. Merging, thanks!