GitOps Toolkit and MonoRepos

[domgreen]

Would like to know if there are any patterns for using the GitOps Toolkit with monorepos?

My current setup has various micro-services that can be versioned independently in the same git repository, each with their own yaml files to be deployed into Kubernetes and SemVer versions.

repo
  - ServerA
    - yaml
    VERSION
  - ServerB
   - yaml
   VERSION

Current Thoughts

Cluster Tagged as a Whole

Currently if there is a single source for this repository would this mean a new version would be needed for the monorepo as a whole?

Therefore thinking as the cluster version as a combination of each of the versions of each of the micro-services present.

e.g. tag 1.0.0

repo
  - ServerA
    - yaml
    VERSION (1.1.1)
  - ServerB
    - yaml
    VERSION (1.2.3) 

With this the gitops-system has a single source for this repo and each change to an individual microservice results in a minor version bump, pulling down the yaml that has changed.

Git Repo uses Many Tags

The alternative would be to have many sources for the same repo that each look after part of the monorepo via a kustomisation and be restricted to using specific tags rather than ranges on a source

e.g tag 1.1.1-ServerA

repo
  - ServerA
    - yaml
    VERSION (1.1.1)
...

e.g tag 1.2.3-ServerB

repo
...
  - ServerB
    - yaml
    VERSION (1.2.3) 

Each source would be locked to a specific tag and ranges could end up being quite dangerous if accidentally selected. This also kinda abuses SemVer due to relying on the pre-release or build additions used.

Rambling Conclusion

Personally, although restrictive in some ways a single source and a version for the cluster as a whole feels more correct initially.

I would like to know what others are doing in this area and any thoughts on the above.

[stefanprodan]

Mono-repo example: https://github.com/fluxcd/flux2-kustomize-helm-example
Multi-repo example: https://github.com/fluxcd/flux2-multi-tenancy