Summary
The RollingSync strategy in ApplicationSet Progressive Syncs requires syncPolicy.automated to be enabled on every generated Application. Once auto-sync is enabled, it triggers on any drift between the source and the live cluster. There is currently no way to scope auto-sync — and therefore Progressive Sync — to a specific kind of change.
This prevents using Progressive Sync to automate one class of change (for example, Helm chart version upgrades) in waves while leaving other classes of change (for example, value or image updates) under manual sync control.
Motivation
Operators frequently want to draw a line between two categories of change:
Infra-level changes (managed by infra teams)— e.g. a Helm chart version upgrade applied uniformly to many Applications. These are infrequent but high blast radius, and benefit greatly from canary / waved rollouts.
App-level changes (managed by dev teams)— e.g. image tags, replica counts, environment variables, value overrides. These are frequent and intentionally kept under human / manual sync control as an operational gate.
With the current Progressive Sync design, the operator must choose: either enable auto-sync (and lose the manual gate on app-level changes), or keep auto-sync off (and lose Progressive Sync entirely). There is no middle ground.
Scoping auto-sync triggers by source-change type would resolve this and make Progressive Sync useful to a much broader set of GitOps workflows.
Proposal
Introduce a way to scope which source-side change types trigger an auto-sync (and therefore a Progressive Sync).
Summary
The RollingSync strategy in ApplicationSet Progressive Syncs requires syncPolicy.automated to be enabled on every generated Application. Once auto-sync is enabled, it triggers on any drift between the source and the live cluster. There is currently no way to scope auto-sync — and therefore Progressive Sync — to a specific kind of change.
This prevents using Progressive Sync to automate one class of change (for example, Helm chart version upgrades) in waves while leaving other classes of change (for example, value or image updates) under manual sync control.
Motivation
Operators frequently want to draw a line between two categories of change:
Infra-level changes (managed by infra teams)— e.g. a Helm chart version upgrade applied uniformly to many Applications. These are infrequent but high blast radius, and benefit greatly from canary / waved rollouts.
App-level changes (managed by dev teams)— e.g. image tags, replica counts, environment variables, value overrides. These are frequent and intentionally kept under human / manual sync control as an operational gate.
With the current Progressive Sync design, the operator must choose: either enable auto-sync (and lose the manual gate on app-level changes), or keep auto-sync off (and lose Progressive Sync entirely). There is no middle ground.
Scoping auto-sync triggers by source-change type would resolve this and make Progressive Sync useful to a much broader set of GitOps workflows.
Proposal
Introduce a way to scope which source-side change types trigger an auto-sync (and therefore a Progressive Sync).