@runeron that’s exactly right, and I’d wager a bet that it’s the same thing @marco-m is after. In k8s world, this would be something like ArgoCD or Flux CD (already mentioned by you), where an operator deployed to the cluster monitors a got repo (our single source of truth) and ensures that in the event there is some external change, then the state is reconciled with git repo.
Example:
A new version of the app is deployed and possibly k8s manifests are updated too. This goes through a rigorous testing and PR and gets merged. The gitops operator sees there is a new version and deploys these updates. Later, there is an issue, and someone starts debugging, changing k8s deployment configs etc. If they forget to submit an updated manifest with any changes they made, the operator will override those, as the git repo is the source of truth. This therefore ensures and enforces to some extent, that developers always commit any ad-hoc changes they may have made.
In Nomad, I’d think something akin to that would be cool. Possibly something in the server stanza config stating which repo to watch, and all job specs get picked up from that repo. Obviously, that would render the nomad cli/ui as useless as the reconciliation would override it.
The problem is that HashiCorp and many others think that GitOps is a one-way thing where a git commit triggers a pipeline that then deploy something. Thats only half the solution.
As some here has mentioned, you need a controller that keeps looking for changes, and enforces the state in git in your cluster.
We have a lot of ideas for the controller, but its still developed in our spare time. It’s not finished, and all contributions are welcome.
We tried Waypoint, but it’s basically doing the same as a Jenkins would do. Pull, build, test and deploy. We want to separate CI and CD from deployment, making releasing/deployment a simple business decision and done by a simple git operation.