SebastienFelix-1A

@alexec : kind of, I guess! The main goal of this feature is to avoid wasting time by waiting for non-related resources to be synced before proceeding a given resource....

Hello @alexec, I will gladly take any feedback if you think this is bad implementation or design. This feature would be very nice to have indeed and I am willing...

I fully agree that a DAG would be the way to go, I think this approach was tried in the PR you mentioned and here it looks like I'm trying...

Well, what I understand from the issue that lead to your PR. The need was exactly parallel waves as describes in the graphs I posted. We, in Amadeus, would also...

Sure, we can discuss that outside here as it could probably be smoother with a quick call! EDIT : I sent you a linkedin request

Hello @ppapapetrou76 , conflict has been resolved. Even if it needs a big refactoring, I want to continue to work on this PR.

Sure, resources will look like that : apiVersion: v1 kind: xxxx metadata: annotations: argocd.argoproj.io/sync-wave: "N" argocd.argoproj.io/sync-wave-order: "BTree" the sync-wave-order label will indicate that we need to use a special mathematical...

Not sure that the config will be meaningfull without the code but here we go : **Resource1 :** apiVersion: v1 kind: xxxx name: resource1 metadata: annotations: argocd.argoproj.io/sync-wave: "1" argocd.argoproj.io/sync-wave-binary-tree-ordering: "true"...

To answer your question about if it could be managed by nesting apps-of-apps: if the binary tree dependency graph gets big, we would need a ton of apps. To my...

@crenshaw-dev I provided complementary information here : https://github.com/argoproj/gitops-engine/pull/744#issuecomment-3041295994