kamel local run/build practices for creating a YAML output

[catshout]

We're running some kind of

kamel run <file>.java -o yaml > <file>.yaml

to create a yaml file for our CD pipeline based on FluxCD.

Does this also work locally w/o a cluster in place? e.g.

kamel local run <file>.java -o yaml > <file>.yaml

With the command I'm getting

Error: unknown shorthand flag: 'o' in -o

So is there any other possibility to create the yaml file without the k8s cluster connectivity?

[squakez]

Not through the kamel local unfortunately. Basically, the local subcommand is in charge to run the java application without knowing anything about Kubernetes. As the Integration is a CRD thought for Kubernetes, it makes sense to have a connected environment taking care of that as well.

[catshout]

Thanks for your reply @squakez.

Background of my question ist that we have an independent CD pipeline. For a YAML creation we need to create every time a Minikube on the build system and drop it afterwards. A lot of effort ..

So the independent (disconnected) YAML creation would be appreciated, if this is possible.

[catshout]

@squakez, @astefanutti, question here as well, might this become a feature request? Or is the connection to the Operator in fact necessary to do things especially for this part of the YAML creation?

[imartinez-tws]

Hi, we are also evaluating camel k and we were wondering if it is possible to externalise the build phase and image generation (e.g. running kamel local build) from an external CI/CD system and just be able to run from generated image. Maybe it is already possible but I haven't found any guideline that explain how to do this.

Thanks in advance.

[squakez]

I got this off my radar... so, I had a further look, and the actual implementation requires the CLI to be connected to a cluster as it delegates the print. I think it can makes sense to have the CLI being able to work disconnected (ie via -o yaml mode). I'm marking this as a feature and we can keep discussing about pros and cons of the "disconnected" approach.

[catshout]

Cool tx > Pasquale Congiusti ***@***.***> hat am 31.03.2022 17:44 geschrieben:

…

I got this off my radar... so, I had a further look, and the actual implementation requires the CLI to be connected to a cluster as it delegates the print <https://github.com/apache/camel-k/blob/main/pkg/cmd/run.go#L631>. I think it can makes sense to have the CLI being able to work disconnected (ie via -o yaml mode). I'm marking this as a feature and we can keep discussing about pros and cons of the "disconnected" approach. — Reply to this email directly, view it on GitHub <#3021 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4N4XIWVJPFC6UKF4UBR63VCXB6RANCNFSM5OVYJGKA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[heiko-braun]

We are doing out of band builds and run the images with operator. @lburgazzoli can provide more details

[imartinez-tws]

Hi, I think the linked PR probably solves the generation of the YAML output with no dependencies to the cluster, but what about the integrationkit image?. Is there any way of producing the image without the cluster and then pass it as a reference whn using kamel run (e.g. kamel run -t container.image=)?

[squakez]

Hello. Yes, you can use container trait for that likely -t container.image=my-kit : https://camel.apache.org/camel-k/next/traits/container.html

Not sure if we can really create the image disconnected from the cluster because, at least you need to publish it to the related registry.

[imartinez-tws]

Hello. Yes, you can use container trait for that likely -t container.image=my-kit : https://camel.apache.org/camel-k/next/traits/container.html

Not sure if we can really create the image disconnected from the cluster because, at least you need to publish it to the related registry.

Thanks for the info.

Well, a CI/CD system usually takes care of image publishing after successful build so it can be referenced by k8s resources on deployment. The idea is keep the operator connected to the registry so it can get the image referenced by container.image, but that image being pushed from CI/CD system.

One of the main advantages of using external CI/CD is that we could have custom version numbers for the releases we are producing