Community Note
- Please vote on this issue by adding a 馃憤 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request
Can you enable support for RollingSync ApplicationSet update strategy?: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#rollingsync
Which service(s) is this request for?
EKS Capabilities
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
It is best described in the ArgoCD docs: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#rollingsync
but in general I would like to limit blast radius of change being rolled out and this looks like a native feature for it. As far as I understood it would only move to a next cluster/env ApplicationSet generation/update if the first defined env updated and resources reported healthy status (this combined with Argo Rollouts could even allow building a self-promotion cross env/cluster pipeline?)
Are you currently working around this issue?
How are you currently solving this problem?
Not sure yet.
Additional context
Anything else we should know?
Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
Community Note
Tell us about your request
Can you enable support for
RollingSyncApplicationSet update strategy?: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#rollingsyncWhich service(s) is this request for?
EKS Capabilities
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
It is best described in the ArgoCD docs: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#rollingsync
but in general I would like to limit blast radius of change being rolled out and this looks like a native feature for it. As far as I understood it would only move to a next cluster/env ApplicationSet generation/update if the first defined env updated and resources reported healthy status (this combined with Argo Rollouts could even allow building a self-promotion cross env/cluster pipeline?)
Are you currently working around this issue?
How are you currently solving this problem?
Not sure yet.
Additional context
Anything else we should know?
Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)