Recommendations for minimal dehydration CI for generating OCIRepository CRs?

[Unveraenderbar]

We really would like to switch to "gitless GitOps" as demonstrated in the Flux D2 reference architecture.

But, adopting this adds a working CI as dependence to the controllability of the GitOps stack – without it, the desired state of the clusters cannot be modified.
Now there are git services that contain a CI ("action runners" in GitHub, GitLab, etc.)... but what does one use if none of those is available?

So what is in use, what is recommended?
Is it really necessary to expand the critical subset for bootstrapping / disaster recovery by another set of CRDs and operators (e.g. self hosted action runners, or even full-fledged Tekton), just to spin up an endpoint that can be wired to git service webhooks, run a dehydration toolstack, and push the result to a OCI registry?

[matheuscscp]

You don't need to dehydrate anything, and I don't quite understand what do you mean by that, to be honest. If you mean running kustomize build or helm template, no, you don't. kustomize-controller and helm-controller do that for you, it's their whole point.

Using OCIRepository does not mean stop using kustomize and helm.

It just means you run flux push artifact somewhere pointing it to two things: the local path where your YAML files are, and the container registry where to push.

That's it. The Flux GitRepository API pulls those files from a Git server. The Flux OCIRepository API pulls them from a container registry.

You can run flux push artifact wherever you want. People normally do it in a CI system connected to Git.

[matheuscscp]

@Unveraenderbar Also, note: the benefit of CI for GitOps is not just using OCI. You also need offline validation for your YAMLs if you don't want to mess up your cluster by doing "push and pray", see this blog post: https://fluxcd.io/blog/2026/07/flux-schema-validation/

[Unveraenderbar]

@matheuscscp this question arose from this suggestion, with the context of remote bases in kustomizations, AFAIU showing the "right way to use them" by decoupling the localization phase (ran in CI at OCI image build time) from the dehydration phase (ran in the GOTK kustomization controller on deployment). That's why I wrote about dehydration above.

Apart from that, yes, sure, we have seen flux schema, experimented with it, and appreciate it very much.
But again: do you consider Tekton or self hosted action runners, or a git service with integrated CI really the absolute minimum necessary for employing gitless GitOps?
And yes, I know the argument about the need of a CI for building container images with business logic anyway, so setting up a few more pipelines for the OCI images used by CM being a negligible effort.
But I think there are differences: if your development container image CI is unavailable, you can't do new releases of your business logic.
If your clusters run in gitless GitOps mode depending on the same CI, you loose controllability once this CI becomes unavailable as you can't change the desired state anymore. IMHO this can be considered worse.
I know quite a few organizations where e.g. running Tekton on a production cluster is a no-go... switching to gitless GitOps would then make controllability of the production cluster dependent of the development clusters... not sure that I like this concept.

As I'm sure I'm not the first one thinking in this direction, I'm asking for something really lightweight – do you really need templates, triggers, tasks, and pipelines for that?
Knative comes to mind, but this seems also overkill to me for bundling some receiver endpoint to the execution of a (compared to real image building pipelines) trivial OCI generation job. I had hoped for something that does not need to deploy CRDs

.

[matheuscscp]

But again: do you consider Tekton or self hosted action runners, or a git service with integrated CI really the absolute minimum necessary for employing gitless GitOps?

Looks like you're trying to force me to say something here?

Flux provides building blocks for you, it does not mandate how you wire them together. I already told you what Flux OCIRepository does (the thing behind Gitless GitOps): it pulls an artifact from a container registry. You can run flux push artifact from your machine if you want. If it's running in a CI system or not, it's totally up to you. You could even use other OCI tools that achieve the same as flux push artifact, it's not a super magical command, it just shoves some files into a container registry, which Flux reads on the other side.

I already gave you my opinion about CI, which I believe matches what the industry has converged to. I'm done arguing about the importance of CI with you. Not sure you are defending your org's decision to disable CI for Git-based automation or if you're just trying to cope with this very unwise decision, but I can't do anything for you there. Now you know how Flux OCIRepository works, it's up to you what you do with it.