Hi there, your questions are coming at the very right time I'm reasoning about the same problems and I'm trying to figure out how to solve them. I'll try to share some of the conclusions I've come to, and some ideas we may be able to develop in the future Camel K versions.
Let's start from the building part. The kamel CLI is just a tool and there is no need to require that into your process. In fact, we're removing pieces little by little and in the long run it should be a very tiny tool with no "intelligent" logic inside or even move entirely the run and bind logic into camel jbang. What I expect is a development cluster where the operator is building the application from the source provided, or, alternatively a CICD which is building a Camel project directly from the maven project you have stored in a git repo. The result would be a container stored into an image repository. The operator can take over the application once it has been built. This application can be tested and validated by the company process. At this stage we can imagine that the Integration custom resource is taken and filled with the values that will make this application to run in any other environment reusing the container image built and tested. This is more or less the approach provided in the gitops blog you've linked. I think we still need to work to make the Integration CR really complete as right now we only fill with the container.image [1]. We can expect the result to be stored back in the git repository in the /camel-k integration folder as a convention with the given overlays (or Helm chart). Once we are done with the validation process, the next stage pipeline (ideally a gitops CD pipeline) takes such an Integration custom resource and deploy to the next stage (for the sake of simplicity, let's say production) applying the related stage overlay (or Helm chart). We can probably improve the tooling in order to make the entire process smooth. Here, the operator would not rebuild the application, but it reuse the very same container image previously built. Moreover we should expect the very same output in term of deployment resources of the development stage (changed by the overlay if it applies). Now, the problematic part is indeed with Kamelets. Those are expected to be previously installed on the cluster. So, I expect an external provisioning process that takes care to install Kamelets and sync every environment you have available. Alternatively you can consider Kamelets as any other resource that has to be bundled with your application (as it would be, for instance, a Configmap). I also know companies that are embedding the Kamelets in their building process in a dependency [2]. Pipe management can be a bit problematic as well, as it does not expose directly all the configuration as the Integration. At the moment I think you can do the same process we've discussed for the Integration, and for the production Pipe, you can specify all the traits parameters required to rebuild the very same Pipe on production via annotation traits [3]. Integration here is a derived resource and should not be altered by anything else than the operator. If we agree this is the right path, we can work on improving the promotion part by setting all required parameters in an Integration/Pipe in order to move across the environments and reproduce the very same behavior [1]. Thanks and regards, Pasquale. [1] I was thinking here some procedure to store the autogenerated trait value in order to reuse them when promoting across environments to be able any operator to do a full reproducible package of CR dependendent on the Integration. [2] https://camel.apache.org/camel-k/next/kamelets/kamelets-distribution.html#kamelets-as-dependency [3] https://camel.apache.org/camel-k/next/kamelets/kamelets-user.html#_trait_via_annotations On Wed, Aug 21, 2024 at 7:46 AM Fabrice Martellucci <marteloud...@gmail.com> wrote: > Hello, > > have you see Argo CD ? is very simple and have many pos. > > good day > > > Le mar. 20 août 2024 à 23:21, Unclear Concept < > unclearontheconc...@gmail.com> > a écrit : > > > I'm hoping for some help with building a CI/CD pipeline for Camel-K > objects > > as part of KNative flows. > > > > For background: I cannot allow write access to the container repo in > PROD, > > and all deployed K8S objects must source from Git (pure gitops, so no > kamel > > CLI at deploy time). These are non-negotiable. I think I see how to > map > > from an Integration to the built container for CI, but I'm not seeing how > > to handle kamelets, or (eg) the implicit Integration for a Pipe. The > goal > > here is to have a fully disjoint CI process that (effectively) produces > K8S > > objects with versioned container references that I can deploy in PROD > > without requiring the kamel CLI etc in any way post-CI. Any pointers? > > > > I'm aware of https://camel.apache.org/blog/2023/07/camel-k-gitops/ and > > https://camel.apache.org/blog/2022/10/camel-k-cicd/ and am trying to > piece > > together a solve within the above constraints. > > > > -- JCL > > >
