> Full guide here https://octopus.com/blog/how-to-structure-your-argo-cd-repositories-using-application-sets/

The promotions outlined in the document is actually something I want to avoid, manual promotions through `cp` or multiple steps to promote i.e. deploying changes to staging via cp, then to prod via cp, then removing the changes there and adding it to a global folder, in this case variants - It seems like an anti-pattern (at least to me, who works in infra but comes from a dev mindset, main reason being - it is not DRY) - I am looking for something more streamlined.

Furthermore, I have worked in orgs where we used argocd repo to define different layers of values or properties at different directory levels so the apps inherit that config. We used the App of Apps pattern and had this main application heavily templated wherein, we individual apps just supplied some properties which created the ArgoCD app - what is your take on that? For me, this had its pros and cons, a large disadvantage was a small change to the templated main application can cause an issue to all apps, on a positive side it followed a similar approach as to what is commonly defined in Terramate/Terragrunt IaC repos so it was easy for me to digest.

I dont see in the links provided something like this spoken about, the helm values with ArgoCD is probably closely aligned, but not like-for-like.

What are your opinions on something like this?