argocd-example-apps VS updatecli

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

Updatecli is a useful tool for fine-tuning update strategies in DevOps. As you've probably experienced, manual updates often result in outdated specs because figuring out what can be updated is tricky.

A second innovation is the use of updatecli to observe the available application helm releases and update the environment helm charts automatically to promote application versions:

Maybe you could have a look to Updatecli https://github.com/updatecli/updatecli

I built https://github.com/updatecli/updatecli for those situations where it's not possible to guess the next tag version. It's a declarative dependency management tool, You define in a manifest how your Yaml should be update, then run updatecli from your CI to automatically open a PullRequest on your repository when a new container tag is available.

Like in this package https://github.com/updatecli/updatecli/tree/main/pkg/plugins...

And the matching between a package and a resource kind is done here