rules_gitops VS kpt

> “You don't need this overengineered goo for your project.”

k8s is probably a great excuse to think how to compose your infrastructure and software in a declarative way - I'm still fascinated by https://demo.kubevious.io/ - It just made "click" when playing with that demo - it's not goo it's a different operating system and a different mindset.

You can do 80% with docker-compose / swarm for small projects but:

If you read HN you are in a huge bubble - gruelsome patched tomcat7 apps on Java8 with 20 properties/ini/xml config files are still popular - hosting things in docker or doing ci/cd is still not mainstream. At least in Europe in the public sector stuff where I was involved.

Sure you can mock it - but the declarative approach is powerful - if you can pull it off to have it across all your infrastructure and code with ci/cd and tests you are fast.

This alone correctly implemented https://github.com/adobe/rules_gitops solves so many problems I can't count the useless meetings we had over any of these bullet points, bazel alone would have solved most major pain points in that project. Just by beeing explizit and declarative.

Don't believe the hype but it's a powerful weapon.

For the kpt tool and kpt kcl SDK, all mutations performed by KCL in place will be checked into git. In reality, KCL is not limited to mutating Kubernetes manifests on the client side. It is also suitable for use in the admission controller (mainly with certain advantages in language features and performance). We also have plans to support the use of KCL by operators in clusters to edit or validate Kubernetes manifests just like Kubevela and CUE language.

Why are you using a conditional in a declaration? There is https://github.com/GoogleContainerTools/kpt

Here is link number 1 - Previous text "kpt"