Is your feature request related to a problem? Please describe.
When using Server-Side Apply (SSA), conflicts can occur if resources are modified outside of Zarf (e.g., kubectl edit or another controller). Since force-conflicts defaults to false, Zarf may be unable to reconcile or correct drift during subsequent deploys.
While Zarf exposes a deploy-time option for --force-conflicts, this puts the burden on the deployer, who may not fully understand whether it is required.
Describe the behavior you'd like
- Given a Zarf package that relies on SSA and expects to enforce declarative state
- When the package is created by an author
- Then the author can specify
forceConflicts: true (globally or per chart/manifest?)
This ensures:
- Zarf automatically applies with
force-conflicts=true during deploys
- Drift is corrected without requiring deploy-time flags
- Behavior is defined by the package author, not the deployer
Describe alternatives you've considered
- Relying on deploy-time
--force-conflicts (adds friction and requires user knowledge)
- Disabling SSA for specific components (works around the issue but loses SSA benefits)
Additional context
This would allow package authors to explicitly choose “drift correction” behavior where appropriate, while keeping the default behavior unchanged for other use cases.
Is your feature request related to a problem? Please describe.
When using Server-Side Apply (SSA), conflicts can occur if resources are modified outside of Zarf (e.g., kubectl edit or another controller). Since force-conflicts defaults to false, Zarf may be unable to reconcile or correct drift during subsequent deploys.
While Zarf exposes a deploy-time option for
--force-conflicts, this puts the burden on the deployer, who may not fully understand whether it is required.Describe the behavior you'd like
forceConflicts: true(globally or per chart/manifest?)This ensures:
force-conflicts=trueduring deploysDescribe alternatives you've considered
--force-conflicts(adds friction and requires user knowledge)Additional context
This would allow package authors to explicitly choose “drift correction” behavior where appropriate, while keeping the default behavior unchanged for other use cases.