add an option to always generate a docker image

[lburgazzoli]

Fixes #246

[nicolaferraro]

Some comments inline..

[nicolaferraro]

?

[lburgazzoli]

bored to roll my own set collection :)

[nicolaferraro]

I think a similar thing should be done for the Knative trait.

[nicolaferraro]

Maybe it makes more sense to move this code in a separate trait, there seems to be two distinct sections in this trait and the deployment trait is not active in all profiles.

[lburgazzoli]

maybe we should add the deployment to all the profiles and differentiate according to the platform ? I can of course create a new trait but then we have to introduce dependencies among traits i.e. the deploy trait need to know if the integration image has to be created or not to determine if configmaps have to be included or not (and maybe something else)

[lburgazzoli]

so I've added some logic in the deploy trait to skip creating resources when running on knative.

btw, I'm wondering if the concept of profiles still matters or if each trait should be responsible about detecting what to do according to the environment.

[nicolaferraro]

I have the same concerns around profiles, but I think the concept is still useful.

I'm also working on the knative side of deployment. I'm going to open a PR. Sometimes the knative side should create a deployment unfortunately, so I've made the knative trait include a deployment trait by composition.. Let's discuss it in the PR.

[lburgazzoli]

maybe a profile should act on the configuration of the traits instead of include/exclude them ?

[nicolaferraro]

Well, sometimes you need to inspect metadata and cluster configuration to understand the flow you've to use.

Their use to exclude completely a trait from the flow (e.g. exclude Knative in std deployment flow) is useful.. I just don't want to over-engineer them..

[lburgazzoli]

yup, don't know what's better.