argocd-example-apps VS argo-rollouts

I have not yet had the opportunity to test flux extensively. Regarding Argo examples, the Argo team themself maintain such a repo: https://github.com/argoproj/argocd-example-apps

Second, when dealing with OCI helm charts, look up the umbrella chart model https://github.com/argoproj/argocd-example-apps/blob/master/helm-dependency/README.md. This basically lets you create a helm chat that doesn’t do anything but call your next helm chart as a dependency. I use this with OCI stores helm charts all over the place. Also, in the next ArgoCD release, you should be able to get multiple sources for a sync, but we’ll see when that comes out

argocd app create helm-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path helm-guestbook --dest-server https://kubernetes.default.svc --dest-namespace default

Let’s Fork a sample repo, for example, like this one found here: https://github.com/argoproj/argocd-example-apps

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: default source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook

For example if I point to https://github.com/argoproj/argocd-example-apps, from the UI, I can see a new repository but no applications

extraObjects: - apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-app namespace: argocd spec: project: default source: repoURL: 'https://github.com/argoproj/argocd-example-apps' path: guestbook targetRevision: HEAD destination: server: 'https://kubernetes.default.svc' namespace: test syncPolicy: automated: {} syncOptions: - CreateNamespace=true EOF

❯ cd ~/git ❯ gh repo fork https://github.com/argoproj/argocd-example-apps.git --clone ✓ Created fork e-minguez/argocd-example-apps Cloning into 'argocd-example-apps'... ... From github.com:argoproj/argocd-example-apps * [new branch] master -> upstream/master ✓ Cloned fork

And support is on it's way for Argo Rollouts 🎉 https://github.com/argoproj/argo-rollouts/pull/2004

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64 chmod +x ./kubectl-argo-rollouts-linux-amd64 sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts kubectl argo rollouts version

kubectl create namespace argo-rollouts kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

You can see in why argo section here what are the limitations of rolling updates and how rollouts solves it: https://github.com/argoproj/argo-rollouts

Argo Rollouts

Check the public users list https://github.com/argoproj/argo-rollouts/blob/master/USERS.md

Supplementary GitOps operators can also be used for deployment strategies, such as canary releases, A/B tests, and blue/green deployments, which have now been grouped under the term “progressive delivery”. The resources of most GitOps operators are not sufficient for this. One solution is Flagger. The tool that was launched by Weaveworks is now being developed as part of the Flux project. The Argo project also has an operator for this use case: Argo Rollouts. Both offer CRs for implementing progressive delivery strategies in interaction with various ingress controllers and service meshes.