Add classpath kamelet loading test

[bouskaJ]

Release Note

NONE

[bouskaJ]

@astefanutti can you review, please?

[squakez]

I have some concern.

I am not sure if we should rely on external kamelet provider, altough it's the official kamelet catalog. I'd prefer to create a copy of the Kamelet we want to test locally instead.
For sure, we should not use a Kamelet that is polling an external service. If the external service is broken, our CI will break as well.

[astefanutti]

LGTM, thanks!

[astefanutti]

@bouskaJ I agree generally with @squakez concern, better have our tests standalone, without any dependency on external systems. If you have time to spare another cycle on this, that'd be great.

[bouskaJ]

I have some concern.

I am not sure if we should rely on external kamelet provider, altough it's the official kamelet catalog. I'd prefer to create a copy of the Kamelet we want to test locally instead.

I am not sure how to make it. The copy of the Kamelet has to be packaged to a maven repository and I didn't find a way how to force jitpack to work with repository subdirs. Can you advise me in this area?

For sure, we should not use a Kamelet that is polling an external service. If the external service is broken, our CI will break as well.

Yes, you are right I will fix it.

[squakez]

I have some concern.
I am not sure if we should rely on external kamelet provider, altough it's the official kamelet catalog. I'd prefer to create a copy of the Kamelet we want to test locally instead.

I am not sure how to make it. The copy of the Kamelet has to be packaged to a maven repository and I didn't find a way how to force jitpack to work with repository subdirs. Can you advise me in this area?

I think you can provide it as a custom resource. I guess you can leverage the API and maybe provide some support method to use that also in the future.

For sure, we should not use a Kamelet that is polling an external service. If the external service is broken, our CI will break as well.

Yes, you are right I will fix it.

[astefanutti]

I think @squakez raised two valid concerns w.r.t. testing stability:

• dependency on an external Kamelet provider: if GitHub availability may be trusted, using main-SNAPSHOT may not (that is trusting ourselves 😄)
• using a Kamelet that depends on a external system

I think the later is the less trustable when it comes to availability guarantee, so the short term solution would be to depend on another Kamelet, without a dependency on an external system, and use a stable version of that Kamelet.

[bouskaJ]

I think @squakez raised two valid concerns w.r.t. testing stability:

• dependency on an external Kamelet provider: if GitHub availability may be trusted, using main-SNAPSHOT may not (that is trusting ourselves smile)
• using a Kamelet that depends on a external system

I think the later is the less trustable when it comes to availability guarantee, so the short term solution would be to depend on another Kamelet, without a dependency on an external system, and use a stable version of that Kamelet.

so I will use a timer kamelet with a released tag of camel-kamelets (v0.3.0 for instance) are you OK with it?

[astefanutti]

so I will use a timer kamelet with a released tag of camel-kamelets (v0.3.0 for instance) are you OK with it?

Sounds good. We can also think about what's the best approach to rely on a local Kamelet. Maybe having it as a resource could work, since Integration resources are added to the classpath.