kustomize: kustomize fails to handle two JSONPatch that add an item to the end of an array

I have a series of array elements (in this case they are https://github.com/argoproj/argo task templates, which can be used independently or chained together) that I would like to keep in individual patches to maximize their reuse.

Each of these patches looks something like this:

- op: add
  path: /spec/templates/-
  value:
    name: clone-repo
    outputs:
      artifacts:
      - name: source
        path: /path
    container:
      image: alpine/git
      command: [sh, -c]
      args: ["git clone --branch {{workflow.parameters.branch}} --depth 1 https://$GITHUB_TOKEN@repo /path"]
      env:
      - name: GITHUB_TOKEN
        valueFrom:
          secretKeyRef:
            name: github-read-only
            key: token

Based on the JSONPatch spec:

A.16.  Adding an Array Value

   An example target JSON document:

   { "foo": ["bar"] }

   A JSON Patch document:

   [
     { "op": "add", "path": "/foo/-", "value": ["abc", "def"] }
   ]

   The resulting JSON document:

   { "foo": ["bar", ["abc", "def"]] }

/spec/templates/- should be added to the array of templates that already exists in a referenced Workflow resource. The issue comes when I try to apply two patches like the one above to the same array of templates. Intuitively I would expect /spec/templates/- to resolve into successive additions to the end of /spec/templates, one for each JSONPatch I add to my kustomization.yaml file.

Currently a collision occurs in this scenario:

Error: found conflict between different patches
&resource.Resource{Kunstructured:(*kunstruct.UnstructAdapter)(0xc0001041b8), b:0} doesn't deep equal &resource.Resource{Kunstructured:(*kunstruct.UnstructAdapter)(0xc000104308), b:0}

Are there any other suggested usage patterns for reuse at this level?

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 6
  • Comments: 21 (6 by maintainers)

Commits related to this issue

Most upvoted comments

@booninite Ever find a solution to this?

Why not instead define an order that patches will be applied in? This would remove all ambiguity, and would be important when ordering on lists does matter(which should be pretty much always, although is unfortunatly often not true in the kubernetes world)