Conflict policies see history edit this page

Talks about: , and

Conflict policies decide what happens when an apply hits an immutable-field conflict — a changed clusterIP, a Job pod template, a StorageClass field that can’t be updated in place. By default the controller fails the stage and reports it, so nothing destructive happens by surprise. A policy opts specific resources into automatic resolution.

The three actions

A default for the whole stage

spec:
  stages:
    - name: app
      sourceRef:
        name: my-app
      conflictPolicy:
        default: Fail            # explicit; the safe default

The force: true shorthand on a stage is equivalent to conflictPolicy.default: Recreate.

Per-resource rules

Rules recreate exactly the resources that need it while everything else stays Fail. A rule’s target is a partial selector — any field you omit matches everything. Rules are evaluated in list order; the first rule whose target matches wins, and an object matching no rule falls back to default.

      conflictPolicy:
        default: Fail
        rules:
          # a Job's pod template is immutable — recreate it on change
          - target:
              apiVersion: batch/v1
              kind: Job
            action: Recreate
          # never fight an HPA over replica counts
          - target:
              kind: Deployment
              name: web
            action: KeepExisting

Recreating storage

Recreating a PersistentVolumeClaim or PersistentVolume destroys data, so a Recreate rule targeting one is refused unless you explicitly accept the loss:

        rules:
          - target:
              kind: PersistentVolumeClaim
              name: scratch
            action: Recreate
            allowDataLoss: true     # required for PVC/PV Recreate, refused otherwise

Without allowDataLoss: true, a Recreate rule targeting a PVC/PV is rejected — a guardrail against accidentally wiping a volume.