If you used fluxcd you could remove the need for terraform and keeping the state. Validation can be done with kubeval. The issue would be connecting fluxcd with the local bare repo, but it could be exposed with a reverse tunnel.

My framework does GitOps for infrastructure automation. It includes the managed K8s and supporting cloud resources. Not just workloads on the clusters.

Only the development environment is local.

Can anyone explain this to me? Is it a sophisticated version of git-hooks?

I needed a way to mock the trigger that would usually be sent from e.g. Github to your CI/CD system. This is what I use the Git hooks for.

The way it works is: To get the post-update hook to trigger, you have to push because post-update is triggered by git-receive-pack after a push. So this is why you create a local remote and push to it. This also mirrors the workflow when using the Kubestack framework for real infrastructure.

The goal for the local development environment was to mirror the real workflow. So that people can also use it to try the framework without having to create real cloud infrastructure.

So the hook also needs to trigger a pipeline. Because the best practice is to have the pipeline live with the code, the post-update script will checkout the pushed commit-hash to a third repository and will call the mock-pipeline shell script that's part of the checkout.

You will then see the terraform plan/apply output as part of the remote output coming from the Git push.

We need a framework for that!

Thank you, and naturally I agree. That's why I am building a GitOps framework. If there is value in building an application on top of a high-level framework like Spring Boot, Ruby on Rails or Django - and there is - then teams should not build the infrastructure and automation from scratch either.